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: Re: [gentoo-user] Updating portage, continued
Great additional information. Thank you. > Gesendet: Mittwoch, 05. Juni 2019 um 00:10 Uhr > Von: "Mick" > An: gentoo-user@lists.gentoo.org > Betreff: 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 > >
Re: Re: [gentoo-user] Updating portage, continued
On Thu, 6 Jun 2019 08:00:07 +0200, n952...@web.de wrote: Please don't top-post. Inline replies are preferred on this list. > 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. There is an element of circularity to this, which can take a bit longer to understand. Once you do, it suddenly all makes sense, and you no longer see the problems that new users can have with the documentation. > 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. Slots are defined in the ebuilds, the developer must decide there is a need for, and implement, the slot behaviour. for example, gcc is slotted - you would normally use the latest version but some software may not build with it so it is useful to have an older version around for those cases. Python is another example already mentioned. > 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. By all means record your experiences, but once you have crossed that initial threshold of understanding, and before you forget it was even there, you could also add any explanations you feel are missing to the Gentoo wiki. -- Neil Bothwick Top Oxymorons Number 17: Clearly misunderstood pgp8kZG3jp_CQ.pgp Description: OpenPGP digital signature
Re: Re: Re: [gentoo-user] Updating portage, continued
> 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. > Multiple versions. Some software only works with a specific version of a dependency, so to ensure wide coverage of dependencies, multiple versions of the same software is required. Eg, some software may only work with python version 2.7 and other software may only work with python 3.6. If both versions of python are still being software maintained, an author may decide its not their top priority to re-write their software that's based on 2.7 to work with 3.6.
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: 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. pgp8PgKkZmSgo.pgp Description: OpenPGP digital signature
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
Re: [gentoo-user] Updating portage, continued
On Tue, 4 Jun 2019 00:14:01 +0200, n952...@web.de wrote: > Fundamentally, autounmask seems like something I don't want to do, at > all. Why do you think that? > What happens if I just remove zz-autounmask? any USE flag changes required by installed ebuilds will be cancelled. > What do I have to emerge to find out? emerge --ask --newuse --update ~world - it will almost certainly complain and want to to add unmask entries. > I currently have: > > $ cat /etc/portage/package.use/zz-autounmask > >=dev-lang/python-2.7.14-r1:2.7 sqlite > >=sys-libs/zlib-1.2.11-r1 minizip > > And, I thought unmasking was related to keywords - allowing or not > allowing experimental versions ... why is that > in /etc/portage/package.use? That's keyword masking - although I agree that the choice of terminology here is a little confusing. autounmask can apply to keywords too, it is a generic concept for when portage needs configuration changes in order to satisfy the requirements of ebuilds. -- Neil Bothwick C: (n.) the language following A and B. The world still awaits D and E. By Z, it may be acceptable for general use. pgpkXiZ5fz1N2.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Updating portage, continued
On Tue, 4 Jun 2019 00:09:40 +0200, 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 This is telling you that monitorix requires rrdtool to be installed with those USE flags, this will be specified in the monitorix ebuild. Portage has only put those settings in a temporary file, it is up to you to check and commit them using etc-update or equivalent. > 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 It looks like you already have rrdtool installed, just not in the configuration needed by monitorix-3.9.0. If you zap or skip it, portage will refuse to install monitorix-3.9.0 because its dependencies are not met. > I would have thought that emerge would pend until I'd agreed to the > override. But, it apparently went ahead and installed. Did you check the output from emerge? It normally exits after an autounmask request to allow you to action it. -- Neil Bothwick WinErr 042: Virus error - A virus has been activated in a dos-box. The virus, however, requires Windows. All tasks will automatically be closed and the virus will be activated again. pgprabRAvesE8.pgp Description: OpenPGP digital signature
Re: Aw: Re: [gentoo-user] Updating portage, continued
On Monday, 3 June 2019 23:14:01 BST n952...@web.de wrote: > Fundamentally, autounmask seems like something I don't want to do, at all. > What happens if I just remove zz-autounmask? What do I have to emerge to > find out? @world with --newuse and --pretend. > I currently have: > > $ cat /etc/portage/package.use/zz-autounmask > > >=dev-lang/python-2.7.14-r1:2.7 sqlite > >=sys-libs/zlib-1.2.11-r1 minizip > > And, I thought unmasking was related to keywords - allowing or not allowing > experimental versions ... why is that in /etc/portage/package.use? autounmask will deal with USE flags as well as keywording testing versions of packages. Portage will ask to autounmask USE flags who may have been affected by a change in an ebuild, or by a change in the default USE flags stipulated by make.profile. However, it is up to you as the maintainer of the system to study both USE and keyword changes and decide what their impact might be on your system. Then accept or reject these changes before you proceed with emerge. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
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 signature.asc Description: This is a digitally signed message part.
Aw: Re: [gentoo-user] Updating portage, continued
Fundamentally, autounmask seems like something I don't want to do, at all. What happens if I just remove zz-autounmask? What do I have to emerge to find out? I currently have: $ cat /etc/portage/package.use/zz-autounmask >=dev-lang/python-2.7.14-r1:2.7 sqlite >=sys-libs/zlib-1.2.11-r1 minizip And, I thought unmasking was related to keywords - allowing or not allowing experimental versions ... why is that in /etc/portage/package.use? > Gesendet: Dienstag, 04. Juni 2019 um 00:09 Uhr > Von: n952...@web.de > An: gentoo-user@lists.gentoo.org > Betreff: Aw: Re: [gentoo-user] Updating portage, continued > > 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 > > 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 > > > 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? > > > > > > Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr > > Von: "Rich Freeman" > > An: gentoo-user@lists.gentoo.org > > Betreff: Re: [gentoo-user] Updating portage, continued > > > > On Wed, May 29, 2019 at 6:37 PM wrote: > > > > > > The next section of the response to my attempt to update portage is a > > > long list of packages, each terminated with a "(masked by: something or > > > other)". > > > > > > What does that tell me. If it's masked, it shouldn't be available, > > > right? But, I've got it: > > > > > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > > > > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > > > > Can I get rid of it? Is perl-parent always masked? > > > > > > > I think one of the issues here is that you might be running a bit with > > scissors. > > > > It seems like you might be using package.keywords, and now you're > > dealing with package masks. > > > > Portage will let you override just about anything, but those default > > behaviors all exist for a reason and you can easily end up painting > > yourself into a corner. Overriding keywords is something that isn't > > too unsafe to do once you know what you're doing, but if you're doing > > it a lot it can get out of hand (adding keywords for one package can > > require 3 more, and if you keep that up it can really get out of > > hand). If you're overriding keywords frequently perhaps you should be > > running the testing branch in the first place, etc. > > > > Overriding masks is something that should only be done if you REALLY > > know what you're doing. If something is masked it might contain > > security vulnerabilities, or it might be going away. The consequences > > of the former are obvious. If it is going away then you're going to > > be fighting to keep things working because the next step will be > > removal and other packages will start being modified to not work with > > the old approach. > > > > Basically, any setting you put in /etc/portage is something you're > > going to have to work to maintain, so you should be doing whatever you > > can to minimize this. By all means speak up on the list about "I'm > > trying to accomplish this, and is there a better way to go about it?" > > If you're creating a ton of entries in /etc/portage you might be > > fighting the package manager more than necessary. There is nothing > > wrong with customizing things (that is basically what Gentoo is for), > > but you definitely need to learn how to manage that so that you don't > > make life hard on yourself. > > > > -- > > Rich > > > > > >
Aw: Re: [gentoo-user] Updating portage, continued
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 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 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? > Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr > Von: "Rich Freeman" > An: gentoo-user@lists.gentoo.org > Betreff: Re: [gentoo-user] Updating portage, continued > > On Wed, May 29, 2019 at 6:37 PM wrote: > > > > The next section of the response to my attempt to update portage is a long > > list of packages, each terminated with a "(masked by: something or other)". > > > > What does that tell me. If it's masked, it shouldn't be available, right? > > But, I've got it: > > > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > > Can I get rid of it? Is perl-parent always masked? > > > > I think one of the issues here is that you might be running a bit with > scissors. > > It seems like you might be using package.keywords, and now you're > dealing with package masks. > > Portage will let you override just about anything, but those default > behaviors all exist for a reason and you can easily end up painting > yourself into a corner. Overriding keywords is something that isn't > too unsafe to do once you know what you're doing, but if you're doing > it a lot it can get out of hand (adding keywords for one package can > require 3 more, and if you keep that up it can really get out of > hand). If you're overriding keywords frequently perhaps you should be > running the testing branch in the first place, etc. > > Overriding masks is something that should only be done if you REALLY > know what you're doing. If something is masked it might contain > security vulnerabilities, or it might be going away. The consequences > of the former are obvious. If it is going away then you're going to > be fighting to keep things working because the next step will be > removal and other packages will start being modified to not work with > the old approach. > > Basically, any setting you put in /etc/portage is something you're > going to have to work to maintain, so you should be doing whatever you > can to minimize this. By all means speak up on the list about "I'm > trying to accomplish this, and is there a better way to go about it?" > If you're creating a ton of entries in /etc/portage you might be > fighting the package manager more than necessary. There is nothing > wrong with customizing things (that is basically what Gentoo is for), > but you definitely need to learn how to manage that so that you don't > make life hard on yourself. > > -- > Rich > >
Re: [gentoo-user] updating portage, continued
On Wed, May 29, 2019 at 6:27 PM wrote: > > Next comes this: > > "The following keyword changes are necessary to proceed: > (see "package.accept_keywords" in the portage(5) man page for more details) > # required by sys-devel/crossdev-20171230::gentoo > # required by @selected > # required by @world (argument) > =sys-apps/portage-2.3.67 ~amd64" > > > If I'm understanding correctly, accept_keywords allow experimental and > development versions. Why should I need that for something as basic as > portage? Is AMD not quite ready for primetime? And, how does portage know? > And what happens if I just ignore that? What consequences can I expect? > I would not accept this change. That version of crossdev is no longer in the repo, but it only depends on >=sys-apps/portage-2.1. Any stable version of portage should satisfy that. I'd need more output to figure out what is going on there. -- Rich
Re: [gentoo-user] Updating portage, continued
On Wed, May 29, 2019 at 6:37 PM wrote: > > The next section of the response to my attempt to update portage is a long > list of packages, each terminated with a "(masked by: something or other)". > > What does that tell me. If it's masked, it shouldn't be available, right? > But, I've got it: > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > Can I get rid of it? Is perl-parent always masked? > I think one of the issues here is that you might be running a bit with scissors. It seems like you might be using package.keywords, and now you're dealing with package masks. Portage will let you override just about anything, but those default behaviors all exist for a reason and you can easily end up painting yourself into a corner. Overriding keywords is something that isn't too unsafe to do once you know what you're doing, but if you're doing it a lot it can get out of hand (adding keywords for one package can require 3 more, and if you keep that up it can really get out of hand). If you're overriding keywords frequently perhaps you should be running the testing branch in the first place, etc. Overriding masks is something that should only be done if you REALLY know what you're doing. If something is masked it might contain security vulnerabilities, or it might be going away. The consequences of the former are obvious. If it is going away then you're going to be fighting to keep things working because the next step will be removal and other packages will start being modified to not work with the old approach. Basically, any setting you put in /etc/portage is something you're going to have to work to maintain, so you should be doing whatever you can to minimize this. By all means speak up on the list about "I'm trying to accomplish this, and is there a better way to go about it?" If you're creating a ton of entries in /etc/portage you might be fighting the package manager more than necessary. There is nothing wrong with customizing things (that is basically what Gentoo is for), but you definitely need to learn how to manage that so that you don't make life hard on yourself. -- Rich
Aw: Re: [gentoo-user] Updating portage, continued
Thanks for the good link > Gesendet: Donnerstag, 30. Mai 2019 um 00:52 Uhr > Von: "Neil Bothwick" > An: gentoo-user@lists.gentoo.org > Betreff: Re: [gentoo-user] Updating portage, continued > > On Thu, 30 May 2019 00:37:14 +0200, n952...@web.de wrote: > > > The next section of the response to my attempt to update portage is a > > long list of packages, each terminated with a "(masked by: something or > > other)". > > > > What does that tell me. If it's masked, it shouldn't be available, > > right? But, I've got it: > > > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > > > Can I get rid of it? Is perl-parent always masked? > > grep perl-parent -r /etc/portage > > will tell you whether one of your config files is masking it. > > Since you have already admitted not updating config files for quite a > while, I would tackle that task first, it may remove some of your other > problems. You should read up on this in the Handbook > https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Tools > > > -- > Neil Bothwick > > Guns don't kill people--it's those little pieces of lead. >
Re: [gentoo-user] Updating portage, continued
On Thu, 30 May 2019 00:37:14 +0200, n952...@web.de wrote: > The next section of the response to my attempt to update portage is a > long list of packages, each terminated with a "(masked by: something or > other)". > > What does that tell me. If it's masked, it shouldn't be available, > right? But, I've got it: > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild > > Can I get rid of it? Is perl-parent always masked? grep perl-parent -r /etc/portage will tell you whether one of your config files is masking it. Since you have already admitted not updating config files for quite a while, I would tackle that task first, it may remove some of your other problems. You should read up on this in the Handbook https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Tools -- Neil Bothwick Guns don't kill people--it's those little pieces of lead. pgpbDSxZPU4fo.pgp Description: OpenPGP digital signature
