This is a discussion to follow up bug #149508 [1]. The bug points to a behaviour change in handling of the profiles file, that, in my opinion at least, needs to be discussed, as there are profiles relying on the old behaviour (Gentoo/FreeBSD's to state some).
For what I can tell, the current behaviour has the advantage of providing a different masking reason for packages that are *needed to some version* for the profile to be complete, and for packages that are know not to work on a profile. Example: Gentoo/FreeBSD relies on profiles masking for sys-freebsd/freebsd-* packages, as you should *not* use freebsd-lib 6.2 on the 6.1 profile, for instance; AMD64 no-multilib profiles use package.mask to mask packages that are known to be broken on that profile. In case of Gentoo/FreeBSD, it also means to have 3x entries for forcing versions of the packages on users. Another reason I'd see for retain the current behaviour is that users are known to unmask stuff via package.unmask to try "might-be-broken" versions. Considering that -* masking is deprecated, this means that if 2.4 profiles released a new version of linux-headers with some experimental support (okay, unlikely, but let's say it happens), it should go in package.mask.. user put linux-headers in package.unmask without a version (which is usually correct, as you might want to unmask newer revisions too), but find himself with linux-headers 2.6 unmasked. I cannot find myself any reason for such a behaviour change, but I'm open to be proven wrong. *Important: do NOT use this thread for considerations on QA behaviour, this is NOT what this post is thought for.* [1] https://bugs.gentoo.org/show_bug.cgi?id=149508 -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpFhi8MeOx9S.pgp
Description: PGP signature