*/lib is reserved for libraries generallyBased on this, I guess it would be right to put DSOs in /usr/lib/<package> and executables in /usr/libexec/<package>
*/libexec is reserved for executables initiated by an already runing program.
linux from scratch limits the use of libexec and we use the option --with-libexec=/usr/bin or /usr/sbin in most cases to eliminate a libexec directory which ends up holding very very few files at all.Yes and no. I think you should still try to keep directories like /usr/bin and /usr/lib nice and tidy, and for instance store programs on /usr/bin only when it's meaningful to execute them on their own. Executables that have a useful function only when started (in some special way) by a different programs should *not* be installed on /usr/bin, or anywhere else on typical executions paths, IMO. I've also been thinking that perhaps /usr/lib should be reserved for files that have true library functionality and are shared by different applications, as opposed to more "private" code put into .so files for technical reasons.
I suggest you use /usr/lib for your things. But why do you want to keep them separated into subdirectories? One of the reasons for using package management systems is to eliminate this need of separating each package into subdirectories.
On the more practical side, one of the reasons I why want to install files outside the normal libdir (or on a subdirectory) is that I sometimes need to package special versions of libs that may already exist in some other form on the target setup - so using the default location is obviously a bad idea because it may lead to file conflicts. And no, I wouldn't package my software like that, either, in an ideal world, or if there wasn't anything called a "deadline", or if I were to install it, not some stupid user ;-/
- Toralf
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
