Aw: Re: Re: [gentoo-user] Updating portage, continued

Or, perhaps, that's where slots come in?

If I try to install package A, which doesn't want whatever's in
   > > > +>=net-analyzer/rrdtool-1.6.0-r1 perl graph
then, it'll use a new slot?

I see that I have ebuilds for rrdtool-1.6.0 and rrdtool-1.7.0,1.7.1. and 1.7.2.  The one that runs when I enter rrdtool is 1.6.0.

Was that caused by etc/portage/package.use/._cfg0015_zz-autounmask  even though I hadn't accepted it yet?
I understand correctly, right, that commands in ._cfg* files pend until accepted?

Basically, this pending change is because monitorix doesn't want to work with the newest version of rrdtool?


> Gesendet: Dienstag, 04. Juni 2019 um 21:56 Uhr
> Von: n952162@×××.de
> An: gentoo-user@l.g.o
> Betreff: Aw: Re:  Re: [gentoo-user] Updating portage, continued
>
> Okay, I think I got it.  I saw that rrdtool was installed, so assumed everything was okay.  But, what I didn't realize is that - back then - I guess I tried to install montorix and didn't notice, in the jungle of messages, that the emerge was not successful.
>
> Apparently, rddtool got installed with harmless, default values, which, however, are not sufficient for  monitorix.  So, now I can accept the changes, and re-emerge rddtool - or probably, emerging monitorix will arrange for that.
>
> Then,  if someday, I get a nasty message that there's a keyword conflict, I'll have to sacrifice either the new package or monitorix ...
>
> In the meantime, I'll install this package and that, and some of them may be dependent on rrdtool.  In that case, unless they explicitly disallow that unmasked version, they'll use the same, possibly experimental, version.  When the day comes that I have to back the unmasked version of rrdtool out, then all other dependent packages will get the standard, default version again.
>
> I'm catching on, bit by bit  ;-)
>
>
>
> > Gesendet: Dienstag, 04. Juni 2019 um 00:50 Uhr
> > Von: "Mick" <michaelkintzios@×××××.com>
> > An: gentoo-user@l.g.o
> > Betreff: Re: Aw: Re: [gentoo-user] Updating portage, continued
> >
> > On Monday, 3 June 2019 23:09:40 BST n952162@×××.de wrote:
> > > 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
> >
> > If you accept the above portage will emerge net-analyzer/rrdtool-1.6.0-r1 with
> > USE flags 'perl' and 'graph' enabled.  This change seems to be required by
> > www-misc/monitorix for some functionality of rrdtool (e.g. graphing) it needs.
> >
> >
> > > 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 <tobi@×××××××.ch>
> >
> > Successful against what criteria?  If monitorix needs/wants it to be compiled
> > so in order to perform graphing, it may not work until you've enabled these
> > USE flags and re-emerged (more successfully this time) rrdtool.
> >
> >
> > > 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?
> >
> > If the changes in USE flags were hardcoded in the ebuild, because without them
> > an insurmountable conflict would arise, I expect portage would refuse to
> > emerge and complain of a hard block [B].
> >
> > --
> > Regards,
> > Mick
>
>