On Tuesday, 4 June 2019 21:21:24 BST n952...@web.de wrote: > 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?
Not really. rrdtool-1.x will be in the same slot, say SLOT="0" for whichever x value the developers release. You will not be able to install rrdtool-1.x and rrdtool-1.xx, without using a prefix or some similar trick. If the developers also released a different slot, e.g. rrdtool-2.x, then this would become SLOT="1" and so on, with its own different versions of build and run time dependencies. You could conceivably have both rrdtool-1.x and rrdtool-2.x installed on the same box, with different USE flags is you so wished or the devs or make.profile stipulated - as long as there was no major blockage in their respective versions of dependencies. Have a look here for a better explanation of SLOTS: https://devmanual.gentoo.org/general-concepts/slotting/ > 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. They all belong to the same slot: $ grep SLOT /usr/portage/net-analyzer/rrdtool/rrdtool-1.*.ebuild /usr/portage/net-analyzer/rrdtool/rrdtool-1.6.0-r1.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.0.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.1.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.2.ebuild:SLOT="0/8.0.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? Yes. Configuration directives in ._cfg* files remain there until accepted or until rejected (zapped) by the user. > Basically, this pending change is because monitorix doesn't want to work > with the newest version of rrdtool? I think it is a matter of USE flags monitorix requires of rrdtool. Looking in the latest stable monitorix ebuild we see: RDEPEND="dev-perl/Config-General dev-perl/DBI dev-perl/HTTP-Server-Simple dev-perl/IO-Socket-SSL dev-perl/libwww-perl dev-perl/MIME-Lite dev-perl/XML-Simple net-analyzer/rrdtool[graph,perl] <== This one dev-perl/CGI" These USE flag requirements for rrdtool are present in all versions of monitorix presently in the tree, see below, but things may have been different in previous monitorix versions not currently in the tree (I'm not familiar with monitorix and its historic dependencies): $ grep rrdtool /usr/portage/www-misc/monitorix/monitorix-*.ebuild /usr/portage/www-misc/monitorix/monitorix-3.10.0-r1.ebuild: net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.10.1.ebuild: net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.11.0.ebuild: net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.9.0.ebuild: net-analyzer/ rrdtool[graph,perl] > > 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 -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
