W dniu sob, 24.03.2018 o godzinie 20∶02 +1300, użytkownik Kent Fredric napisał: > On Fri, 23 Mar 2018 11:53:40 +0100 > Ulrich Mueller <[email protected]> wrote: > > > Still, masking is the wrong way to express such preferences. If you > > package.mask sys-devel/gcc then you say that something is wrong with > > that package. Which I believe is not what you want to express here. > > I might have a better usecase for adding masks from overlays. > > But its more for the usecase of "there isn't something wrong with that > package", but the more frequent usecase of "Portage is stupid and so we > have masks to coerce the right behaviour" > > For example, if I had an overlay that's sole purpose was to > test/transition experimental versions of Perl, where the presumption > was that by installing said overlay, that you wished to upgrade to that > version of Perl, it might make sense to employ masks to prevent portage > doing dumb things. > > And by "Dumb things", I mean some of the common problems I see where > portage tries to solve a blocker by downgrading Perl.... > > Its much simpler to just author a blacklist of "Look, these are things > that are known to be a mess, don't even consider installing them, with > a nice description of why this is nonsense" > > Trying to achieve it by any other means simply tempts the problem to > reappear in another form, because everything *other* than package.mask > will have portage try to flip the USE flag to try to make it work, and > end up with people needing --backtrack=1000 and having it still not > work. > > package.mask is at least a "look, we know this is nonsense, don't even > explore this line of reasoning" blunt instrument.
...except that it is also used to say 'this is experimental version, unmask at will' and Portage wants to unmask stuff for you anyway. Well, I mean the default configuration of Portage, not mine. -- Best regards, Michał Górny
