There is quite some stir right now in the gentoo-dev mailing list following a mass-masking and for removal of packages for QA and security reasons; I think that Alec nailed down most of the issues with his comments:
> This thread is yet another proof that we need to introduce a “Upcoming
> masking” for unmaintained packages.<sarcasm>
Shall I file those forms in triplicate and fax them to the main office sir?
</sarcasm>
Since amazingly I actually started the Treecleaners project; the
intent was actually to fix problems with packages. Part of the
problem is that there are hundreds of packages in the tree and the
fixes vary in complexity so it is difficult to create hard-and-fast
rules on when to keep a package versus when to toss it. One of the
things I like about masking is that it quickly gets people who
actually care about the package up to bat to fix it instead of leaving
it broken for months. I realize maintainers do not exactly enjoy this
kind of poking, however when things have been left for long enough I
believe our options become a bit more limited (in this case, masking
for removal due to unfixed sec bugs.)
Now, this is one issue I already partly addressed in my post about the five minutes fix myth but I’d like to remind again that even though we can easily spot some blatant problems with packages, having a package that compiles and that passes the obvious, programmatic QA checks does not really tell you much about the health status of the package; indeed, you won’t know whether the package works at all for the final users. Tying to another post of mine (incidentally, someone complained about my self-reference to posts… should I stop giving pointers and context?), I have to admit that sometimes it’s impossible to have a 100% coverage of packages, among other reasons because some packages need particular hardware, or particular software components set up, to be able to test them effectively. On the other hand, when such a complex setup isn’t strictly needed, we should expect some level of testing when making changes, minor or otherwise.
Sometimes, the mistakes are in the messages logged by the ebuild, at other times, the problem is that some important part of the package is missing, for example because the install phase is manually written in the ebuild, and upstream has added some extra utility that is installed by make install but is obviously ignored by the ebuild (and this actually is one of the points that Donnie brought up when I suggested to override upstream build systems with an eclass: we’d have to triple-check the new releases to make sure that no further source files or objects or libraries were added from the previously-packaged version). All these things are almost impossible to identify in a nice, programmatic scripted way, and need knowledge of a package, checking the release notes having an idea how to test the package.
For instance, I’ve been looking into sys-libs/libnss-pgsql today, as I have an interest on it; the ebuild installs the shared library manually (skipping libtool’s relinking phase, by the way); why did it do that? It takes four steps rather than the one needed for make install… well, the reason was obvious (but not commented upon!) after changing it to use make install: a post-install check actually aborted the merge: the problem was that the package installed the Name Service Switch library in /lib, but also installed the static archive and the libtool .la file, both of which are definitely not needed in /lib. The handwritten install solution solves the symptoms but not the following problems:
- it will still build the static archive (non-PIC) version, causing twice the number of compiler calls;
- it won’t tell upstream that they forgot one thing in their
Makefile.am; - it’s still wrong because the libraries it links to are not available in
/lib: it won’t be working before mounting/usrif/usris on a different partition (who does still do that, nowadays?!) — it should be in/usritself, at this point (and yes, you can do that: both GNU libc and FreeBSD – which has a different NSS interface by the way – check both/usrand/usr/lib).
Incidentally, why does glibc’s default nsswitch.con use db files for services, protocols, svc and ethers? Their presence in there means that each time you call into glibc to resolve a port name, it makes eight open() syscalls trying to find the file. It doesn’t sound too right.
I have patches, and I have a new ebuild, I’ll see to send them upstream and get it committed (by someone else, or by picking maintainership for it) in the next day or so. In the mean time I have to get back to my work.
No, just add an extra link for them, to http://en.wikipedia.org/wiki/Special:Random, so that when they are <sarcasm>forced</sarcasm> to click on a link, it doesn’t have to be to another of your posts.
“if /usr is on a different partition (who does still do that, nowadays?!)”Um, that’ll be me, I grossly underestimated root fs size …… and /opt – doom3 and quake4 were explosively large.
“mounting /usr if /usr is on a different partition (who does still do that, nowadays?!) “Me too. It is much easier to have a relatively small root system, with /var, /opt, /usr and /home on lvm partitions. Of course, root can also be on lvm, but it is somewhat harder to maintain.
I sincerely don’t think that it’s worth keeping @/usr@ split… now I can understand cases like Jim’s (where you’re trying to cover for a mistake after all), but there is no advantage, though a lot of disadvantages, in having @/usr@ on a different partition…I’m the first one to say that @/home@ *should* be split, and maybe @/var@ (I just split _some_ parts of @/var@) but for @/usr@ it’s definitely not worth the hassle.I have a 30G root, and then split @/home@, @/var/cache@, @/var/tmp@ and, thanks to the @FEATURES=splitdebug@, @/usr/lib/debug@ (which, alone, would be 6GB of stuff!). Oh, and of course I don’t use @/usr/portage@ there, as otherwise it would really have to stay on its own partition, that stuff is in @/var/cache@.
> Oh, and of course I don’t use /usr/portage there, as otherwise it would really have to stay on its own partition, that stuff is in /var/cache.That bothers me a lot. Why portage tree is placed in /usr but not, for example, in /var/pkg?
And another one who has /usr on a different partition. This really saved me recently when messing around with btrfs for /usr and some other partitions and hitting a partition full condition because portage writes in /usr and btrfs did not like all the small files repeatedly being rewritten at that point in time.Recovering from a full /usr partition is simply much easier if you have it separate from root.
The reason why @/usr/portage@ is placed as it is is because Portage was inspired, originally, by the FreeBSD ports system that stays in… @/usr/ports@…As many agree, it’s not really the best approach: FreeBSD has a very different filesystem layout than we have in Linux, and there you get a _very_ small @/@ and a _huge_ @/usr@ if you follow the default partitioning scheme.And moesasji, you ended up having that problem *because* we have @/usr/portage@ that is full of small files. You wouldn’t have mocked up with the filesystem for @/usr@ if it wasn’t for Portage, would you?
Yeah, whipper-snappers keep saying that.I use separate /usr and make two / filesystems, one at the beginning of the disk and one at the end. This makes broken systems more rescuable when I’m impatient.Yes, absolutely, very little should be expected to work without /usr, and certainly multi-user login is one of the things that has never been expected to work so trying to make PAM work without /usr is overzealous. A reasonable alternative these days to (dual-rescue) separate root would probably be a big fat ramdisk miniroot that’s a little more like a livecd and less like an early userspace.But also please remember that the original reason for segregating /usr was to NFS share it read-only among a large cluster. /usr is supposed to not contain any config files, hence “system resource,” static stuff. The connection between root fs and booting was exigent but not essential, not the base cause of /usr’s invention. This read-only-shared case is still highly relevant for clusters, zones, VM’s, whatever. Filesystems like btrfs/zfs that allow super-efficient snapshots and clones may eventually subsume this case, but we’re certainly not there yet.HTH.
@carton oh I know that and you’re right… on the other hand I sincerely would just keep around an USB rescue system or a full-blown mini-system for rescue rather than having @/usr@ separate… at the end what does it change if I have full system or just part of it?As for the clustering thing, that’s true and right… the point that I tried to make is that @/usr@ *has no reason to exist separate for the average desktop system*. Like @/boot@, that has a lot of uses as a separate partition for most advanced use cases, the _average_ system has no need for it.