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

[Mick]

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