Fundamentally, autounmask seems like something I don't want to do, at all. What happens if I just remove zz-autounmask? What do I have to emerge to find out?
I currently have: $ cat /etc/portage/package.use/zz-autounmask >=dev-lang/python-2.7.14-r1:2.7 sqlite >=sys-libs/zlib-1.2.11-r1 minizip And, I thought unmasking was related to keywords - allowing or not allowing experimental versions ... why is that in /etc/portage/package.use? > Gesendet: Dienstag, 04. Juni 2019 um 00:09 Uhr > Von: n952...@web.de > An: gentoo-user@lists.gentoo.org > Betreff: Aw: Re: [gentoo-user] Updating portage, continued > > I'm sorry, I'm not getting this yet. What if I just don't update these > configuration files? > > dispatch-conf tells me, for /etc/portage/package.accept_keywords: > > --- /etc/portage/package.use/zz-autounmask 2018-03-12 21:56:49.172491972 > +0100 > +++ /etc/portage/package.use/._cfg0015_zz-autounmask 2018-07-28 > 11:08:23.725995803 +0200 > @@ -1,2 +1,5 @@ > >=dev-lang/python-2.7.14-r1:2.7 sqlite > >=sys-libs/zlib-1.2.11-r1 minizip > +# required by www-misc/monitorix-3.9.0::gentoo > +# required by monitorix (argument) > +>=net-analyzer/rrdtool-1.6.0-r1 perl graph > > I can zap it or merge it or skip it. It looks like the emerge was > successful, so, why should I do anything? > > $ rrdtool > RRDtool 1.6.01.6.0 Copyright by Tobias Oetiker <t...@oetiker.ch> > > > I would have thought that emerge would pend until I'd agreed to the override. > But, it apparently went ahead and installed. > So what's required still? What will be different once I make the merge to > zz-autounmask? > > > > > > Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr > > Von: "Rich Freeman" <ri...@gentoo.org> > > An: gentoo-user@lists.gentoo.org > > Betreff: Re: [gentoo-user] Updating portage, continued > > > > On Wed, May 29, 2019 at 6:37 PM <n952...@web.de> wrote: > > > > > > The next section of the response to my attempt to update portage is a > > > long list of packages, each terminated with a "(masked by: something or > > > other)". > > > > > > What does that tell me. If it's masked, it shouldn't be available, > > > right? But, I've got it: > > > > > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > > > > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > > > > Can I get rid of it? Is perl-parent always masked? > > > > > > > I think one of the issues here is that you might be running a bit with > > scissors. > > > > It seems like you might be using package.keywords, and now you're > > dealing with package masks. > > > > Portage will let you override just about anything, but those default > > behaviors all exist for a reason and you can easily end up painting > > yourself into a corner. Overriding keywords is something that isn't > > too unsafe to do once you know what you're doing, but if you're doing > > it a lot it can get out of hand (adding keywords for one package can > > require 3 more, and if you keep that up it can really get out of > > hand). If you're overriding keywords frequently perhaps you should be > > running the testing branch in the first place, etc. > > > > Overriding masks is something that should only be done if you REALLY > > know what you're doing. If something is masked it might contain > > security vulnerabilities, or it might be going away. The consequences > > of the former are obvious. If it is going away then you're going to > > be fighting to keep things working because the next step will be > > removal and other packages will start being modified to not work with > > the old approach. > > > > Basically, any setting you put in /etc/portage is something you're > > going to have to work to maintain, so you should be doing whatever you > > can to minimize this. By all means speak up on the list about "I'm > > trying to accomplish this, and is there a better way to go about it?" > > If you're creating a ton of entries in /etc/portage you might be > > fighting the package manager more than necessary. There is nothing > > wrong with customizing things (that is basically what Gentoo is for), > > but you definitely need to learn how to manage that so that you don't > > make life hard on yourself. > > > > -- > > Rich > > > > > >
