[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Profile masking and profiles package.mask
From:       Mike Frysinger <vapier () gentoo ! org>
Date:       2006-09-30 17:39:58
Message-ID: 200609301339.58887.vapier () gentoo ! org
[Download RAW message or body]

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

[Attachment #3 (application/pgp-signature)]
-- 
gentoo-dev@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]