bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25273: address@hidden: 'mc' package needs some fixes]


From: ng0
Subject: bug#25273: address@hidden: 'mc' package needs some fixes]
Date: Mon, 26 Dec 2016 13:19:58 +0000

ng0 <address@hidden> writes:

> ng0 <address@hidden> writes:
>
>> Leo Famulari <address@hidden> writes:
>>
>>> ----- Forwarded message from ng0 <address@hidden> -----
>>>
>>> Date: Wed, 21 Dec 2016 21:40:31 +0000
>>> From: ng0 <address@hidden>
>>> To: address@hidden
>>> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]