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

Great additional information.  Thank you.

> Gesendet: Mittwoch, 05. Juni 2019 um 00:10 Uhr
> Von: "Mick" <michaelkintzios@×××××.com>
> An: gentoo-user@l.g.o
> Betreff: Re: Aw: Re:  Re: [gentoo-user] Updating portage, continued
>
> On Tuesday, 4 June 2019 21:21:24 BST n952162@×××.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: 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
>
>
> --
> Regards,
> Mick