On Wed, Feb 22, 2012 at 7:46 AM, Harald Hoyer <harald.hoyer@xxxxxxxxx> wrote: > Am 21.02.12 14:37, schrieb Miloslav Trmač: >> On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer <harald.hoyer@xxxxxxxxx> wrote: >>> Am 20.02.2012 21:19, schrieb Miloslav Trmač: >>>> On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers <kay.sievers@xxxxxxxx> 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. <snipped> > 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. *shrug* What I really care about in this discussion is that incorrect claims that LSB/FHS mandates/allows something don't become accepted as general knowledge. Recently there have been rather many instances of "X is the standard and you need to follow it to stay compatible" when X were way too new to be considered a standard. Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
