Am 21.02.12 14:37, schrieb Miloslav Trmač: > On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer <harald.ho...@gmail.com> wrote: >> Am 20.02.2012 21:19, schrieb Miloslav Trmač: >>> On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers <kay.siev...@vrfy.org> wrote: >>>> There is no reason to have >>>> /usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that >>>> only a _single_ dir should be used, hence the one in lib not in share. >>> Chapter and verse, please? AFAICS all LSB says is >>> http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html >> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA >> >> /usr/lib : Libraries for programming _and_ packages >> >> Applications may use a single subdirectory under /usr/lib. If an application >> uses a subdirectory, > > There is equivalent language in the /usr/share section, with no > indication that the two are supposed to be exclusive. > >> all architecture-dependent data exclusively used by the >> application must be placed within that subdirectory. > > Again, equivalent language in the /usr/share section talks about > architecture-independent data. When coupled with the front parts of > FHS, it's quite clear that the intent is to split the application's > data between the two directories. > > BTW, pedantic reading of FHS seems not to support at all the concept of an > application-defined directory into which other applications are > supposed to store additional files. That's a pretty unreasonable > interpretation, however. > > (I think there is sort of a good reason not to require doing the lib > vs. share split in Fedora - adding one more directory to check is a > not a packaging change, it is a semantic change, it > would be now necessary to somehow handle the case when lib and share > each contain a different file with the same name. In my view, a lot > of the "interesting" udev and systemd really belong to /etc anyway...) > Mirek
Well, as recently stated on the FHS mailing list, the FHS just documents common practice and does not set new standards. So, if we want a new standard in the FHS, we will have to invent, document and ship it. Same thing was happening when Red Hat/Fedora started with /usr/libexec and /run. It's now documented, even though only RH/Fedora uses /usr/libexec. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
