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: n952...@web.de > An: gentoo-user@lists.gentoo.org > 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" <michaelkintz...@gmail.com> > > An: gentoo-user@lists.gentoo.org > > Betreff: Re: Aw: Re: [gentoo-user] Updating portage, continued > > > > On Monday, 3 June 2019 23:09:40 BST n952...@web.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 <t...@oetiker.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 > >
