This is a discussion to follow up bug #149508 .
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
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.*
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE