GNU bug report logs - #25273
[ng0@libertad.pw: 'mc' package needs some fixes]

Previous Next

Package: guix;

Reported by: Leo Famulari <leo <at> famulari.name>

Date: Mon, 26 Dec 2016 02:47:02 UTC

Severity: normal

Done: Leo Famulari <leo <at> famulari.name>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 25273 <at> debbugs.gnu.org (full text, mbox):

From: ng0 <ng0 <at> libertad.pw>
To: 25273 <at> debbugs.gnu.org
Subject: Re: bug#25273: [ng0 <at> libertad.pw: 'mc' package needs some fixes]
Date: Mon, 26 Dec 2016 13:52:33 +0000
ng0 <ng0 <at> libertad.pw> writes:

> ng0 <ng0 <at> libertad.pw> writes:
>
>> ng0 <ng0 <at> libertad.pw> writes:
>>
>>> Leo Famulari <leo <at> famulari.name> writes:
>>>
>>>> ----- Forwarded message from ng0 <ng0 <at> libertad.pw> -----
>>>>
>>>> Date: Wed, 21 Dec 2016 21:40:31 +0000
>>>> From: ng0 <ng0 <at> libertad.pw>
>>>> To: guix-devel <at> 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




This bug report was last modified 6 years and 103 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.