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:19:58 +0000 Message-ID: <87h95qltdt.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> 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]:38402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLVC9-0007vp-Gg for bug-guix@gnu.org; Mon, 26 Dec 2016 08:20:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLVC6-0000gm-AU for bug-guix@gnu.org; Mon, 26 Dec 2016 08:20:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:40005) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cLVC6-0000ga-73 for bug-guix@gnu.org; Mon, 26 Dec 2016 08:20:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cLVC5-0000vn-Pp for bug-guix@gnu.org; Mon, 26 Dec 2016 08:20:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k2amltyn.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: > >> 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 -- ♥Ⓐ ng0 PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org