Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
On 2019.06.06 18:38, Ilya Trukhanov wrote: Namely x11-libs/libX11 and dev-libs/glib: - libX11 failed during configure because it couldn't find xcb; - glib failed during configure because it couldn't find libmount. Looks like it is an order issue, because after rebuilding x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built just fine. Should I report bugs for these? The news item says: >If you have any problems with the new profiles or the migration >procedure, please report a bug and make it block the tracker. But I'm a little reluctant to do so for various reasons. I'm in the same situation. I've had several rebuild failures that succeeded after re-emerging one/some of what they depend on, although I would have expected those to also be rebuilt. I wonder if the instructions should be "emerge -1 --deep /lib32 /usr/lib32" ? I'll have to try it once I'm done with the current set of emerges. Anyway - it probably does make sense to file the bug - the worst they will do is close it as not a bug, and hopefully at least tell you what you should have done to avoid the problem.
[gentoo-user] Packages failed to build during 17.0 -> 17.1 migration
Namely x11-libs/libX11 and dev-libs/glib: - libX11 failed during configure because it couldn't find xcb; - glib failed during configure because it couldn't find libmount. Looks like it is an order issue, because after rebuilding x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib built just fine. Should I report bugs for these? The news item says: >If you have any problems with the new profiles or the migration >procedure, please report a bug and make it block the tracker. But I'm a little reluctant to do so for various reasons. signature.asc Description: Digital signature
Re: [gentoo-user] What is the best way to clean up the world file?
Jack wrote: > On 6/6/19 1:37 PM, Grant Taylor wrote: >> On 6/6/19 10:50 AM, Jack wrote: >> >>> I'm not going to even try regenworld, as I'm in the midst of >>> converting to the 17.1 profile, and have quite a number of packages >>> that don't yet seem to cope with that change well. >> >> Fair. >> >> I'm not thinking about the 17.0 to 17.1 migration yet. > It still seems not quite ready for prime time. >> I'm wondering what, if anything I need to do to clean up gcc: >> >> % gcc-config -l >> [1] x86_64-pc-linux-gnu-6.4.0 * >> [2] x86_64-pc-linux-gnu-8.2.0 >> [3] x86_64-pc-linux-gnu-8.3.0 >> >> I seem to remember going from older /to/ 6.4 being a bit touchy. > I currently have only 8.3.0 installed, and I don't remember having any > problems with the upgrade from whatever previous version I was using. > I assume (can't remember) that I did rebuild a number of other > packages before/when I removed the older version(s), but my current > rig is far too slow to even consider an "emerge world" (would take at > least a week) so I'm pretty selective about rebuilding stuff. > > I don't recall having any problems with the GCC upgrade either. I'd check the news items to be sure if anything special needs to be done but I don't recall anything. Dale :-) :-)
Re: [gentoo-user] What is the best way to clean up the world file?
On June 6, 2019 5:43:07 PM UTC, Jack wrote: >On 6/6/19 1:37 PM, Grant Taylor wrote: >> On 6/6/19 10:50 AM, Jack wrote: >> >>> I'm not going to even try regenworld, as I'm in the midst of >>> converting to the 17.1 profile, and have quite a number of packages >>> that don't yet seem to cope with that change well. >> >> Fair. >> >> I'm not thinking about the 17.0 to 17.1 migration yet. >It still seems not quite ready for prime time. >> I'm wondering what, if anything I need to do to clean up gcc: >> >> % gcc-config -l >> [1] x86_64-pc-linux-gnu-6.4.0 * >> [2] x86_64-pc-linux-gnu-8.2.0 >> [3] x86_64-pc-linux-gnu-8.3.0 >> >> I seem to remember going from older /to/ 6.4 being a bit touchy. >I currently have only 8.3.0 installed, and I don't remember having any >problems with the upgrade from whatever previous version I was using. >I >assume (can't remember) that I did rebuild a number of other packages >before/when I removed the older version(s), but my current rig is far >too slow to even consider an "emerge world" (would take at least a >week) >so I'm pretty selective about rebuilding stuff. Check the Gentoo GCC upgrade guide. It lists versions from which the default method won't work correctly. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/6/19 1:37 PM, Grant Taylor wrote: On 6/6/19 10:50 AM, Jack wrote: I'm not going to even try regenworld, as I'm in the midst of converting to the 17.1 profile, and have quite a number of packages that don't yet seem to cope with that change well. Fair. I'm not thinking about the 17.0 to 17.1 migration yet. It still seems not quite ready for prime time. I'm wondering what, if anything I need to do to clean up gcc: % gcc-config -l [1] x86_64-pc-linux-gnu-6.4.0 * [2] x86_64-pc-linux-gnu-8.2.0 [3] x86_64-pc-linux-gnu-8.3.0 I seem to remember going from older /to/ 6.4 being a bit touchy. I currently have only 8.3.0 installed, and I don't remember having any problems with the upgrade from whatever previous version I was using. I assume (can't remember) that I did rebuild a number of other packages before/when I removed the older version(s), but my current rig is far too slow to even consider an "emerge world" (would take at least a week) so I'm pretty selective about rebuilding stuff.
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/6/19 10:50 AM, Jack wrote: I've been going through this lately also (mainly due to forgetting -1 on updates) and put together a script, which I can post later if anyone wants. However, the bottom line for me is to do "emerge -pc package" for each package in world to see what (if anything) else pulled it in. If it was pulled in by something else, I remove it from the world file, unless I explicitly want it installed. The script just does most of that, producing a file that makes it easier for me to see what -pc would remove and what is actually installed. Interesting concept and methodology. I'll have to pontificate that. Currently my world file is 292 lines, with 1863 packages installed (from "eix-installed -a".) ACK I'm not going to even try regenworld, as I'm in the midst of converting to the 17.1 profile, and have quite a number of packages that don't yet seem to cope with that change well. Fair. I'm not thinking about the 17.0 to 17.1 migration yet. I'm wondering what, if anything I need to do to clean up gcc: % gcc-config -l [1] x86_64-pc-linux-gnu-6.4.0 * [2] x86_64-pc-linux-gnu-8.2.0 [3] x86_64-pc-linux-gnu-8.3.0 I seem to remember going from older /to/ 6.4 being a bit touchy. -- Grant. . . . unix || die
Re: [gentoo-user] What is the best way to clean up the world file?
On 2019.06.06 11:59, Grant Taylor wrote: On 6/6/19 9:57 AM, Grant Taylor wrote: It seems as if the regenworld script adds things that it finds from /var/log/emerge.log that aren't themselves dependencies of something else. Thus it the world file is cleaner than if all installed packages were in the world file. To put some numbers to it, regenworld crates a new world file that is ~250 lines on a machine that has > 950 packages installed (as reported by emerge -DuNeq @world). So it's better. But I think I still need to clean the world file. I've been going through this lately also (mainly due to forgetting -1 on updates) and put together a script, which I can post later if anyone wants. However, the bottom line for me is to do "emerge -pc package" for each package in world to see what (if anything) else pulled it in. If it was pulled in by something else, I remove it from the world file, unless I explicitly want it installed.The script just does most of that, producing a file that makes it easier for me to see what -pc would remove and what is actually installed. Currently my world file is 292 lines, with 1863 packages installed (from "eix-installed -a".) I'm not going to even try regenworld, as I'm in the midst of converting to the 17.1 profile, and have quite a number of packages that don't yet seem to cope with that change well. Jack
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/6/19 9:57 AM, Grant Taylor wrote: It seems as if the regenworld script adds things that it finds from /var/log/emerge.log that aren't themselves dependencies of something else. Thus it the world file is cleaner than if all installed packages were in the world file. To put some numbers to it, regenworld crates a new world file that is ~250 lines on a machine that has > 950 packages installed (as reported by emerge -DuNeq @world). So it's better. But I think I still need to clean the world file. -- Grant. . . . unix || die
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/5/19 10:56 PM, Dale wrote: It's a plain text file and I've edited it in the past with no problems. ACK I /thought/ that was the case. But I wanted to double check that there wasn't something else filed away that needed to match before I edited the file. I've done that cleanup before and it can take some time to accomplish depending on how bad it is. I went through this when I first started using Gentoo and didn't know any better. I'd do small chunks and keep a versioned back up file just in case. *nod* I've also used the script once. It does fairly well. It may miss a couple here and there and may have a few false positives as well. It seems as if the regenworld script adds things that it finds from /var/log/emerge.log that aren't themselves dependencies of something else. Thus it the world file is cleaner than if all installed packages were in the world file. However, there are still some things that aren't dependencies of other things that are listed that are no longer needed. The world file is 279 lines long. I'm just going to go through the file by hand and identify every package listed and make a judgment call if I know if it needs to be on the system or not. If it does, then I'll leave it. If it doesn't then I'll remove it from the world file and let emerge decide if it needs to stay or not. There's a massive --depclean in this systems future. Still it can do some heavy lifting for you. I'd copy the world file to a safe place and try the script. I'd try it once with the old world file in place and once without a world file at all. Then see which one works best. If that fails, do it manually. ACK Good luck. I hope one or the other works. Thank you. -- Grant. . . . unix || die -- Grant. . . . unix || die
Re: [gentoo-user] What is the best way to clean up the world file?
On 6/6/19 1:36 AM, Mick wrote: On Thursday, 6 June 2019 05:56:53 BST Dale wrote: Grant Taylor wrote: On 6/5/19 9:18 PM, Dale wrote: I would start by removing anything that has libs in it. Generally, those should be pulled in as deps. After that, I'd go through the list and remove anything that you don't directly use. ACK Can I just edit /var/lib/portage/world? Or do I need to do something else? Yes, manually edit this file, but FIRST MAKE A BACK UP. :-) If you don't feel comfortable doing that `emerge --deselect` will remove things from the world file without altering it's state on the machine (i.e. you will have to --depclean to remove packages.) Dan
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 > > > 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,
Re: [gentoo-user] What is the best way to clean up the world file?
Mick wrote: > On Thursday, 6 June 2019 09:56:24 BST Neil Bothwick wrote: >> On Thu, 06 Jun 2019 09:36:03 +0100, Mick wrote: >>> I think, but may be wrong, regenworld will pick up anything and >>> everything in emerge.log and add it to your world file. Definitely >>> create a back up of / var/lib/portage/world if you do not have one >>> already, because you can diff it later on to see how much weight it has >>> put on. >> I think it only adds packages that are not a dependency of something >> else, which may result in a world file that is too lean and >> over-enthusiastic depcleaning later on. >> >> Another method, a time consuming one, is to remove the world file and run >> emerge -p --depclean. Then emerge -n anything in the output that you use >> directly. Rinse and repeat. Eventually the depclean output will only >> contain unneeded packages, at which point you can run it in anger. > I haven't used it for a long time, so its behaviour may have > changed/improved. > The last time I used it I got a *very* long list of "package XXX was added to > your world file" kind of message and stopped using it ever since. I may have > run it the wrong way - not sure - but thought of warning Grant just in case. > With a back up in hand, which I foolishly did not have handy as I was rushing > at the time, it is easy to revert any unwelcome changes. > > As Dale mentioned my original problem (a fat/polluted world file) would have > been easily resolved if I used 'emerge -1' each time I manually tried to sort > out some portage output. I think I've learned this lesson well. ;-) > And if you are a old fart who has bad memory like me, put it in the make.conf as a default. That way it takes no effort to keep a clean world file but does take effort to add something to the world file. I have to rebuild a individual package a lot more than I need to install a new package. I learned long ago, don't trust my memory to do things by default. Heck, I have to think about it to remember to add the -N to regular updates still. I been doing that for years. If it wouldn't screw up other things, I'd set it as a default but that causes another set of issues. Go ahead, tell me to do updates in script. ROFL Dale :-) :-)
Re: [gentoo-user] What is the best way to clean up the world file?
On Thursday, 6 June 2019 09:56:24 BST Neil Bothwick wrote: > On Thu, 06 Jun 2019 09:36:03 +0100, Mick wrote: > > I think, but may be wrong, regenworld will pick up anything and > > everything in emerge.log and add it to your world file. Definitely > > create a back up of / var/lib/portage/world if you do not have one > > already, because you can diff it later on to see how much weight it has > > put on. > > I think it only adds packages that are not a dependency of something > else, which may result in a world file that is too lean and > over-enthusiastic depcleaning later on. > > Another method, a time consuming one, is to remove the world file and run > emerge -p --depclean. Then emerge -n anything in the output that you use > directly. Rinse and repeat. Eventually the depclean output will only > contain unneeded packages, at which point you can run it in anger. I haven't used it for a long time, so its behaviour may have changed/improved. The last time I used it I got a *very* long list of "package XXX was added to your world file" kind of message and stopped using it ever since. I may have run it the wrong way - not sure - but thought of warning Grant just in case. With a back up in hand, which I foolishly did not have handy as I was rushing at the time, it is easy to revert any unwelcome changes. As Dale mentioned my original problem (a fat/polluted world file) would have been easily resolved if I used 'emerge -1' each time I manually tried to sort out some portage output. I think I've learned this lesson well. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] What is the best way to clean up the world file?
On Thu, 06 Jun 2019 09:36:03 +0100, Mick wrote: > I think, but may be wrong, regenworld will pick up anything and > everything in emerge.log and add it to your world file. Definitely > create a back up of / var/lib/portage/world if you do not have one > already, because you can diff it later on to see how much weight it has > put on. I think it only adds packages that are not a dependency of something else, which may result in a world file that is too lean and over-enthusiastic depcleaning later on. Another method, a time consuming one, is to remove the world file and run emerge -p --depclean. Then emerge -n anything in the output that you use directly. Rinse and repeat. Eventually the depclean output will only contain unneeded packages, at which point you can run it in anger. -- Neil Bothwick People who eat natural foods die from natural causes. pgpyT9uhIkjXb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] What is the best way to clean up the world file?
Mick wrote: > On Thursday, 6 June 2019 05:56:53 BST Dale wrote: >> Grant Taylor wrote: >>> On 6/5/19 9:18 PM, Dale wrote: I would start by removing anything that has libs in it. Generally, those should be pulled in as deps. After that, I'd go through the list and remove anything that you don't directly use. >>> ACK >>> >>> Can I just edit /var/lib/portage/world? Or do I need to do something >>> else? > Yes, manually edit this file, but FIRST MAKE A BACK UP. :-) > > >> It's a plain text file and I've edited it in the past with no problems. >> I've done that cleanup before and it can take some time to accomplish >> depending on how bad it is. I went through this when I first started >> using Gentoo and didn't know any better. I'd do small chunks and keep a >> versioned back up file just in case. >> >> I've also used the script once. It does fairly well. It may miss a >> couple here and there and may have a few false positives as well. Still >> it can do some heavy lifting for you. I'd copy the world file to a safe >> place and try the script. I'd try it once with the old world file in >> place and once without a world file at all. Then see which one works >> best. If that fails, do it manually. >> >> Good luck. I hope one or the other works. >> >> Dale >> >> :-) :-) > I think, but may be wrong, regenworld will pick up anything and everything in > emerge.log and add it to your world file. Definitely create a back up of / > var/lib/portage/world if you do not have one already, because you can diff it > later on to see how much weight it has put on. > >From the help info, I think that is what it is saying. However, when I used it last time, many years ago, it would somehow figure out what is dependencies. From what I recall, it didn't do a bad job. As you say tho, backup the file before doing anything. At least then there is something to refer back to. Of course, it may be a option to just start from a empty world file and add back what is really needed and just keep running --depclean to see what needs to be added back to the world file. This is like updating a old un-maintained system. In some cases it is best to reinstall but in some it may not take much effort to do the updates just in smaller steps. Thing is, one doesn't know until one starts the process. It all depends on so many variables. Plus, we ain't the ones doing it either. lol Dale :-) :-)
Re: [gentoo-user] What is the best way to clean up the world file?
On Thursday, 6 June 2019 05:56:53 BST Dale wrote: > Grant Taylor wrote: > > On 6/5/19 9:18 PM, Dale wrote: > >> I would start by removing anything that has libs in it. Generally, > >> those should be pulled in as deps. After that, I'd go through the > >> list and remove anything that you don't directly use. > > > > ACK > > > > Can I just edit /var/lib/portage/world? Or do I need to do something > > else? Yes, manually edit this file, but FIRST MAKE A BACK UP. :-) > It's a plain text file and I've edited it in the past with no problems. > I've done that cleanup before and it can take some time to accomplish > depending on how bad it is. I went through this when I first started > using Gentoo and didn't know any better. I'd do small chunks and keep a > versioned back up file just in case. > > I've also used the script once. It does fairly well. It may miss a > couple here and there and may have a few false positives as well. Still > it can do some heavy lifting for you. I'd copy the world file to a safe > place and try the script. I'd try it once with the old world file in > place and once without a world file at all. Then see which one works > best. If that fails, do it manually. > > Good luck. I hope one or the other works. > > Dale > > :-) :-) I think, but may be wrong, regenworld will pick up anything and everything in emerge.log and add it to your world file. Definitely create a back up of / var/lib/portage/world if you do not have one already, because you can diff it later on to see how much weight it has put on. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
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. >
