From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: bug#25273: [ng0@libertad.pw: 'mc' package needs some fixes] Date: Mon, 26 Dec 2016 13:52:33 +0000 Message-ID: <87eg0ulrvi.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> References: <20161226024602.GA1997@jasmine> <87mvfilusw.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> <87k2amltyn.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> <87h95qltdt.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLVi7-0004wm-8H for bug-guix@gnu.org; Mon, 26 Dec 2016 08:53:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLVi2-0003tw-UI for bug-guix@gnu.org; Mon, 26 Dec 2016 08:53:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:40018) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cLVi2-0003tm-Qo for bug-guix@gnu.org; Mon, 26 Dec 2016 08:53:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cLVi2-0001lA-Ei for bug-guix@gnu.org; Mon, 26 Dec 2016 08:53:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87h95qltdt.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 25273@debbugs.gnu.org ng0 writes: > ng0 writes: > >> ng0 writes: >> >>> Leo Famulari writes: >>> >>>> ----- Forwarded message from ng0 ----- >>>> >>>> Date: Wed, 21 Dec 2016 21:40:31 +0000 >>>> From: ng0 >>>> To: guix-devel@gnu.org >>>> Subject: 'mc' package needs some fixes >>>> >>>> Is someone interested in fixing our `mc' package? It is >>>> functional, but some parts of it are not functional for Guix. Grep >>>> for "/bin/" in the directory of $(guix build mc) shows results >>>> which assume the existence of /bin/ (not >>>> /gnu/store/.../bin/$binary, where I don't mean shebangs but >>>> further down in the scripts. >>>> -- >>>> ♥Ⓐ ng0 | PGP keys and more: https://n0is.noblogs.org/ >>>> | http://ng0.chaosnet.org >>>> >>>> >>>> ----- End forwarded message ----- >>> >>> 92 results, most of them do not seem to be very >>> complicated. Before I start with this, do we adjust "help" files >>> too? I mean when we open the HELP function of an application it >>> should reflect what our system does and not some non-existent >>> defaults for other systems. >> >> Some extension of mc will make the size of its graph grow. >> I personally don't care about the size, but others might. So: >> should I follow my vim example and put those changes into mc-full >> or should the default be an fully functional mc with all 2nd and >> 3rd level dependencies (which are not obvious as mc doesn't print >> error messages)? > > To give an example why I think this is important, we have > absolute paths left over which are expected to just work on other > systems with no hard dependencies on those applications. MC will > work without them, but various extensions, like those below are > just disfunctional without a reason. Until you grep its store > location for obvious reasons, you will just think the application > is faulty or your file is broken, or whatever you happen to think > of, as for other systems it just happens to work. MC has no > possibility to display error messages for these extension (in > most cases). Three examples: > > libexec/mc/extfs.d/uzip:18:my $app_zip = "/usr/bin/zip"; > libexec/mc/extfs.d/uzip:20:my $app_unzip = "/usr/bin/unzip"; > share/mc/syntax/Syntax:196:file \\.procmailrc$ Procmail\sRC\sFile ^#/usr/bin/procmail Further questions: Which applications provide "/usr/bin/open"? -- ♥Ⓐ ng0 PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org