Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Profile masking and profiles package.mask
Date: Sat, 30 Sep 2006 17:45:06
Message-Id: 200609301339.58887.vapier@gentoo.org
In Reply to: [gentoo-dev] Profile masking and profiles package.mask by "Diego 'Flameeyes' Pettenò"
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

Replies

Subject Author
Re: [gentoo-dev] Profile masking and profiles package.mask "Diego 'Flameeyes' Pettenò" <flameeyes@g.o>