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
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page