On Saturday 30 September 2006 00:40, Diego 'Flameeyes' Pettenò wrote: > 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.
isnt that the point of putting a comment above a mask ? # this package wont work on this profile bar/foo # these versions are needed in this profile =cat/meow-1* > 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. i dont get it ... if you mask the versions in package.mask, why do you need a packages entry at all ? fbsd/packages:sys-freebsd/freebsd-mk-defs fbsd/package.mask:<nothing> fbsd/6.1/packages:<nothing> fbsd/6.1/package.mask:>=sys-freebsd/freebsd-mk-defs-6.2 fbsd/6.2/packages:<nothing> fbsd/6.2/package.mask:<nothing> > 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. so what you're arguing is that we should retain the existing behavior because users might try to unmask something properly ? trying to protect users from shooting themselves in the foot by making the profile behavior more complicated is a waste of time -mike
pgpFy0pw8RGlW.pgp
Description: PGP signature
