At the moment, I see the following that are invalid: /usr/adm /usr/doc /usr/docs /usr/$CHOST /usr/info /usr/man /usr/portage (This will eventually have to be moved. /usr/tmp (If this is really required, it should point to
At the moment, I see the following that are invalid: /usr/adm /usr/doc /usr/docs /usr/$CHOST /usr/info /usr/man /usr/portage (This will eventually have to be moved. /usr/tmp (If this is really required, it should point to /var/tmp, not ../var/tmp. Otherwise, it should be removed.)
the point of the symlinks is to make sure packages that are not FHS friendly do not break ... and the answer is not always 'fix' them because in the cases where you're dealing with a binary package, it may refer to /usr/man or /usr/tmp or /usr/what-have-you and it may die as for /usr/tmp being ../var/tmp instead of /var/tmp, all symlinks should be relative like that for the most part ... makes for a good habit and when messing around with chroots it could easily save you from headaches
Packages that are not FHS-friendly should break so that we can identify them, and fix them.
did you not fully read my previous comment ? you *cannot* fix *everything*
So you
So youre saying that Gentoo is notand will never becompliant?
yes, FHS is a guideline, not a strict set of rules that either you live or die by. FHS is not the end-all be-all guide of how your FS should be after all, we 'violate' it with other packages (kde,qt), simply for sake of simplicity
Sounds like laziness, not simplicity.
you're really quite unbelievable (1) *why* should we follow FHS ? why not LSB ? what makes one better than the other ? (2) why dont you produce binary patches to fix binary packages (3) if a user wants to use an older package not in portage, but it is FHS compliant, should we tell them 'hey, too bad, if it aint FHS we dont care' once again, FHS is a guideline, not Gentoo policy ... so, unless you have something constructive to contribute, let this bug die
LSB and FHS are separate standards. There
LSB and FHS are separate standards. Theres no reason whu Gentoo cannot be compliant with them both. If we are handing out binary packages that are broken, then a bug report should be filed so it can be fixed. With the symbolic links, there is no way of even knowing what is broken and what is not, though I believe that the vast majority of packages are ending up in the correct directory because of how dodoc(?) and similar programs do their job (Im not totally sure how that works, so dont quote me). And if a user is installing an FHS-compliant package that isnt in Portage Why should we be yelling at him that it isnt FHS-compliant?
i meant 'isnt' and you can just run `qpkg -f /usr/man` to see all packages that violate the /usr/man FHS spec as for binary packages, you cant fix them all, it's simply impossible i was thinking something else about the LSB ... when i remember what i wanted to say i'll post it ... we've already had requests for LSB implementations, and so far we've declined to write scripts for it ...
qpkg -f /usr/man only shows sys-apps/baselayout *.
thats because i've filed bugs and gotten the packages that *used* to install incorrectly fixed lets get back to the point, you want these legacy links removed because they violate FHS ... i say leave them in because they allow legacy apps to not clutter the filesystem w/non FHS directories
At least if we remove the symbolic links, our distribution will not be broken by default.
the /usr/adm, /usr/docs, and /usr/$CHOST are bugs that lie elsewhere, they arent part of baselayout only doc, man, and tmp exist by default ... and again, i say leave them in for backwards compat portage already has a schedule for changing it's FHS layout, review the bug about it basically i still say this is not a bug, but it's az's final call
I am confident azarah will make the right decision. :)
The /usr/$CHOST issue will not change, as it is fairly woven into cross compiling in linux (or whatever that use gnu tools). As for the rest, the following on my system is not fixed: ------------------------------------------------ nosferatu patch # epm -qf /usr/man dvdrip-0.50.14 XML-Parser-2.33 Test-Harness-2.30 PDL-2.4.0-r1 File-Spec-0.84-r1 Test-Simple-0.47-r1 MP3-Info-1.02-r1 Digest-MD5-2.27 Inline-0.44-r1 baselayout-1.8.6.10 lilo-22.5.6-r3 nosferatu patch # epm -qf /usr/doc gnome-vfs-2.2.5 gnome-vfs-1.0.5-r3 PDL-2.4.0-r1 indent-2.2.9 baselayout-1.8.6.10 nosferatu patch # ------------------------------------------------- And I do not think the symlinks should go until they are, and support portage side is added to check for stuff in /usr/{doc,man,info} and then warn/error out if a package use them ...
Should bugs be filed against each offending package? I certainly don
Should bugs be filed against each offending package? I certainly dont want to flood Bugzilla with a bunch of fairly identical reports.
ok, to go over the original list again /usr/adm some package installed this, file a bug against that package if it still misbehaves /usr/docs same as above /usr/doc /usr/info /usr/man i'll update the 1.11.x ebuilds to no longer install these symlinks ... packages that install there are broken and should have bugs filed against each one /usr/$CHOST this isnt going to ever change, forget about it /var/tmp i'll fix the symlink to conform to FHS
baselayout-1.11.3+ does this now file bugs for other packages
