Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On 06/10/19 22:42, Rich Freeman wrote: On Mon, Jun 10, 2019 at 5:39 PM n952162 wrote: On 06/06/19 06:00,n952...@web.de wrote: In trying to update portage (before I update my system), I have this: !!! All ebuilds that could satisfy ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been mas !!! One of the following masked packages is required to complete your request: - dev-python/setuptools-::gentoo (masked by: EAPI 7) - dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7) - dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7) - dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7) - dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7) - dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7) - dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot conflict) - dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot conflict) Looking athttps://packages.gentoo.org/packages/dev-python/setuptools shows that the only two versions stable for am64 are 40.6.3 and 36.7.2. What is backtracking and how can I have a slot conflict if it's the developers who determine what version sits in a slot? Backtracking refers to how the dependency resolver works - it couldn't figure out a way to satisfy your requirements. You have a slot conflict because two different packages that you asked for require two different versions of setuptools to be installed at the same time in the same slot, or at least that is what portage interprets what it is finding. The verbose output (attached) says that the package with /"new SLOT installation (side-by-side versions)" /is: dev-lang/python-3.6.5:3.6/3.6m The version in /var/db/pkg/dev-lang/python-* is: /var/db/pkg/dev-lang/python-3.5.4-r1/python-3.5.4-r1.ebuild:SLOT="3.5/3.5m" That doesn't look like the same slot... How can there be a slot collision? If the developers say, slot 3 is for a particular version, why should anybody want to push anything else into slot 3? I'd need to see more of the output to get a sense of what is actually going on - posting 10 lines out of what was probably 1000+ lines of output honestly doesn't help anybody to assist you. Yes, the whole output is tedious but probably contains clues. Gladly! I've attached the output of this command: sudo emerge --verbose y --verbose-conflicts --verbose-slot-rebuilds --oneshot portage 2>&1 | tee emerge-portage-2.txt I presume that the flags in front of the dependency list are those given in the --pretend option of emerge(1) ... One might say, I have a package already dependent on setuptools and it's not the right one, but how can it be that two different versions want to go into the same slot? There are many ways this can happen. Maybe package A wants setuptools 40.7.3 or greater, and package B wants setuptools 40.6.3 or lesser, and you asked for both. But isn't that exactly what slots are supposed to address? How can there be a conflict? A limited number of slots? Often though it is an issue with not backtracking enough - if you're doing a huge update often you need to add --backtrack=100 or rarely even a larger value in order for portage to find a way to meet the requirements. Can I follow the backtracking in this attached output somehow, to see what how backtracking works? Sometimes you need to include --with-bdeps=y because something portage isn't considering in-scope is pulling in something that conflicts, and it could be resolved by letting portage update more packages. Backtracking is something to do with dependency checking. I haven't seen any explanation of what goes on in dependency checking and why backtracking is necessary. Can someone point to an explanation? Basically your config files, like the world file, and the profile system set, contain a list of stuff you want. Portage wants to give you want you want. Maybe these files specify 200 packages you're interested in directly. Each of these might ask for 5 more, and each of those 5 more, and so on. Portage works backwards through the dependency tree to generate a list of every requirement of every package. These can form circular loops, and the tree can get quite large very quickly. As an optimization I believe portage avoids traversing the entire thing and only goes back so far - usually it can find a solution to your requirements without traversing the entire tree. I'm trying to understand that ... A -> + | + -> B ->+ || |+ -> C[0] |+ -> D | + -> C[1] Okay, so backtracking is ... when I'm at C[1] and see there's already a C[0] ... Then I go back to B to see if it might be happy with C[1]? !!! Your current profile is deprecated and not supported anymore. !!! Use eselect profile to
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On Mon, Jun 10, 2019 at 5:39 PM n952162 wrote: > > On 06/06/19 06:00, n952...@web.de wrote: > > In trying to update portage (before I update my system), I have this: > > !!! All ebuilds that could satisfy > ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" > have been mas > !!! One of the following masked packages is required to complete your request: > - dev-python/setuptools-::gentoo (masked by: EAPI 7) > - dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7) > - dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7) > - dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot > conflict) > - dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot > conflict) > > Looking at https://packages.gentoo.org/packages/dev-python/setuptools shows > that the only two versions stable for am64 are 40.6.3 and 36.7.2. > > What is backtracking and how can I have a slot conflict if it's the > developers who determine what version sits in a slot? Backtracking refers to how the dependency resolver works - it couldn't figure out a way to satisfy your requirements. You have a slot conflict because two different packages that you asked for require two different versions of setuptools to be installed at the same time in the same slot, or at least that is what portage interprets what it is finding. I'd need to see more of the output to get a sense of what is actually going on - posting 10 lines out of what was probably 1000+ lines of output honestly doesn't help anybody to assist you. Yes, the whole output is tedious but probably contains clues. > > One might say, I have a package already dependent on setuptools and it's not > the right one, but how can it be that two different versions want to go into > the same slot? There are many ways this can happen. Maybe package A wants setuptools 40.7.3 or greater, and package B wants setuptools 40.6.3 or lesser, and you asked for both. Often though it is an issue with not backtracking enough - if you're doing a huge update often you need to add --backtrack=100 or rarely even a larger value in order for portage to find a way to meet the requirements. Sometimes you need to include --with-bdeps=y because something portage isn't considering in-scope is pulling in something that conflicts, and it could be resolved by letting portage update more packages. > Backtracking is something to do with dependency checking. I haven't seen any > explanation of what goes on in dependency checking and why backtracking is > necessary. Can someone point to an explanation? Basically your config files, like the world file, and the profile system set, contain a list of stuff you want. Portage wants to give you want you want. Maybe these files specify 200 packages you're interested in directly. Each of these might ask for 5 more, and each of those 5 more, and so on. Portage works backwards through the dependency tree to generate a list of every requirement of every package. These can form circular loops, and the tree can get quite large very quickly. As an optimization I believe portage avoids traversing the entire thing and only goes back so far - usually it can find a solution to your requirements without traversing the entire tree. The --backtrack option controls how far back portage will try going. Increasing the value will slow things down, but can't hurt anything. > > My emerge output goes on to say: > > The current version of portage supports EAPI '6'. You must upgrade to a > newer version of portage before EAPI masked packages can be installed. > (dependency required by "app-portage/gemato-::gentoo" [ebuild]) > (dependency required by > "sys-apps/portage-2.3.66-r1::gentoo[-build,rsync-verify]" [ebuil > (dependency required by "portage" [argument]) > For more information, see the MASKED PACKAGES section in the emerge > man page or refer to the Gentoo Handbook. > > Is this telling me that I have to *first* update my system and *then* update > portage? So, if you blindly follow portage's instructions there is a good chance that you'll make your life using Gentoo a living nightmare, because portage doesn't really know what you want and often will get in over its head. The risk of this happening goes up quickly if you wait a long time between updates, as you seem to have done. You probably don't need those EAPI 7 packages, but if you do then the version of portage you have can't install them. You could upgrade portage to gain access to more packages, but you should probably get the system consistent with whatever repos you have synced now before you go updating even further. I'd step back
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On 06/06/19 06:00, n952...@web.de wrote: The handbook is great information, but unfortunately, it uses concepts - specific gentoo concepts - that many readers doesn't know. They are then often cross-referenced to other pages, which likewise define things based on expected internal understanding of the mechanisms, goals, and potential scenarios. I have "read" the handbook - multiple times. But not really understood what it was saying - and I have decades of development experience. Consider slots. I'm sure I've read that slots are used to allow multiple ... versions? configurations? of the same package to be installed. It was gradually dawning on me, that it's the developer who specifies the slot. Now, I can't figure out what use case that benefits, but the ability to have slots react to realities at a particular installation see to me to make a lot of sense. So, there must be something basic that I don't understand. I think cases like my simple case would help new comers and I'm hoping to make a blog describing it, once I fully understand the implications. In trying to update portage (before I update my system), I have this: /!!! All ebuilds that could satisfy ">=dev-python/setuptools-34[python_targets_pypy(-)?,pn_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-pyth-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been mas// //!!! One of the following masked packages is required to complete your request:// //- dev-python/setuptools-::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-41.0.1::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-41.0.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.9.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.8.0::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.7.3::gentoo (masked by: EAPI 7)// //- dev-python/setuptools-40.6.3::gentoo (masked by: backtracking: slot conflict)// //- dev-python/setuptools-36.7.2::gentoo (masked by: backtracking: slot conflict)/ Looking at https://packages.gentoo.org/packages/dev-python/setuptools shows that the only two versions stable for am64 are 40.6.3 and 36.7.2. What is *backtracking* and how can I have a *slot conflict *if it's the developers who determine what version sits in a slot? One might say, I have a package already dependent on /setuptools/ and it's not the right one, but how can it be that two different versions want to go into the same slot? Backtracking is something to do with dependency checking. I haven't seen any explanation of what goes on in dependency checking and why backtracking is necessary. Can someone point to an explanation? My emerge output goes on to say: /The current version of portage supports EAPI '6'. You must upgrade to a// //newer version of portage before EAPI masked packages can be installed.// //(dependency required by "app-portage/gemato-::gentoo" [ebuild])// //(dependency required by "sys-apps/portage-2.3.66-r1::gentoo[-build,rsync-verify]" [ebuil// //(dependency required by "portage" [argument])// //For more information, see the MASKED PACKAGES section in the emerge// //man page or refer to the Gentoo Handbook.// / Is this telling me that I have to *first* update my system and *then* update portage?
Aw: Re: Re: [gentoo-user] Updating portage, continued
The handbook is great information, but unfortunately, it uses concepts - specific gentoo concepts - that many readers doesn't know. They are then often cross-referenced to other pages, which likewise define things based on expected internal understanding of the mechanisms, goals, and potential scenarios. I have "read" the handbook - multiple times. But not really understood what it was saying - and I have decades of development experience. Consider slots. I'm sure I've read that slots are used to allow multiple ... versions? configurations? of the same package to be installed. It was gradually dawning on me, that it's the developer who specifies the slot. Now, I can't figure out what use case that benefits, but the ability to have slots react to realities at a particular installation see to me to make a lot of sense. So, there must be something basic that I don't understand. I think cases like my simple case would help new comers and I'm hoping to make a blog describing it, once I fully understand the implications. > Gesendet: Mittwoch, 05. Juni 2019 um 00:31 Uhr > Von: "Neil Bothwick" > An: gentoo-user@lists.gentoo.org > Betreff: Re: Re: [gentoo-user] Updating portage, continued > > On Tue, 4 Jun 2019 21:56:14 +0200, n952...@web.de wrote: > > > 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. > > It will, portage lnows that monitorix needs rrdtool with the extra USE > flags and will take care of it, now you have given it permission. > > > 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. > > You aren't changing the version, this has nothing to do with keyword > masking. You will get the same version of rrdtool, but with extra > features compiled in - that's what USE flags do. > > > I'm catching on, bit by bit ;-) > > It can take a while, but you would probably find it useful to read the > rest of the Gentoo Handbook. Many people read it to install and boot > their Gentoo system, but that is only the first part. The rest contains > useful information on running and maintaining a Gentoo system. > > > -- > Neil Bothwick > > A pessimist is an optimist who's given it some thought. >
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
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" > > > An: gentoo-user@lists.gentoo.org > > > Betreff: Re: Aw: Re: [gentoo-user] Updating portage, continued > > > > > > On Monday, 3 J
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: 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" > > 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-autounmask2018-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 > > > > 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 > >
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" > 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-autounmask2018-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 > > 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
