On 04/03/2012 05:34 PM, Bruce Dubbs wrote:
> Armin K. wrote:
>
>> I do not agree with /usr/libexec stuff ... I'd agree if it only
>> installed executables there, or even better -
>> /usr/libexec/package/{executable1,executable2,etc} ... But no, it
>> installs also directories there, too which is sort of mess ... And yet
>> some more stuff ... Some (well, at least most of gnome) packages install
>> files in /usr/lib/package and /usr/libexec/package, and I'd rather keep
>> it in one directory. Anyways, if there are only executables installed, I
>> recommend moving them in /usr/bin or /usr/sbin (depends on how it would
>> be run).
>
> When I read the purpose, it says:
>
> "Applications which use /usr/libexec in this way must not also use
> /usr/lib to store internal binaries, though they may use /usr/lib for
> the other purposes documented here."
>
> Looking at the /usr hierarchy, I see that we now have
> /usr/libexec/coreutilities with one file: libstdbuf.so.  That doesn't
> look like an executable to me, but I suspect that it is a library that
> only coreutils needs to know about and it dynamically loaded by those
> programs that need it.
>
> I do wonder what apps use it because it will break any command that may
> need it before /usr is mounted.
>
> In any case, our policy has been to generally go with what upstream
> designed unless it breaks some standard.  Since it appears that the
> standard is changing, we shouldn't make explicit changes to avoid
> /usr/libexec.
>
> I would hope that each package that uses it would create an application
> specific subdirectory.
>
>     -- Bruce

I am still against this one as long as packages create directory in 
/usr/lib and /usr/libexec or even just install their stuff without even 
creating and installing it into package subdirectory, so we would get 
some kind of bin and lib dir put together or whatever ...
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to