Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
El mié, 03-11-2021 a las 21:15 -0500, John Helmert III escribió: > On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote: > > On 4 Nov 2021, at 00:02, Sam James wrote: > > > > On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > > > > Is that where the policy belongs? > > > > If so, shouldn't the council update it based on their decisions? > > > > "patches are welcome" doesn't fit every scenario. > > > Got to agree here. If there's a gap in the documentation, > > > let's file a bug -- irrespective of if someone is going to give > > > a patch. > > > Just commenting this on the ML means it'll get lost > > > and we'll forget about it... > > > > Filed https://bugs.gentoo.org/821553. Please > > feel free to clarify it. > > Thank you! Many of us apparently have differing interpretations of the > policy (and it's somewhat hidden), so a clear policy in an obvious > place will be a huge improvement! I haven't tried yet as, fortunately, I have been able to deal with the conflicts most of the times but, I was wondering if one workaround would be to simply try to use emerge-webrsync --revert= option. That way, people could try to upgrade their old systems going from the oldest tree to, for example, the tree from August of this year. Later they could update to a newer snapshot and follow until the end signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote: > On 4 Nov 2021, at 00:02, Sam James wrote: > >> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > >> Is that where the policy belongs? > >> If so, shouldn't the council update it based on their decisions? > >> "patches are welcome" doesn't fit every scenario. > > Got to agree here. If there's a gap in the documentation, > > let's file a bug -- irrespective of if someone is going to give > > a patch. > > Just commenting this on the ML means it'll get lost > > and we'll forget about it... > > Filed https://bugs.gentoo.org/821553. Please > feel free to clarify it. Thank you! Many of us apparently have differing interpretations of the policy (and it's somewhat hidden), so a clear policy in an obvious place will be a huge improvement! signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On 4 Nov 2021, at 00:02, Sam James wrote: >> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: >> Is that where the policy belongs? >> If so, shouldn't the council update it based on their decisions? >> "patches are welcome" doesn't fit every scenario. > Got to agree here. If there's a gap in the documentation, > let's file a bug -- irrespective of if someone is going to give > a patch. > Just commenting this on the ML means it'll get lost > and we'll forget about it... Filed https://bugs.gentoo.org/821553. Please feel free to clarify it. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > Is that where the policy belongs? > If so, shouldn't the council update it based on their decisions? > "patches are welcome" doesn't fit every scenario. Got to agree here. If there's a gap in the documentation, let's file a bug -- irrespective of if someone is going to give a patch. Just commenting this on the ML means it'll get lost and we'll forget about it... Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 10:32:34PM +0100, Ulrich Mueller wrote: > > On Wed, 03 Nov 2021, Aaron Bauman wrote: > > > I love digging through old council logs to find "policy" > > > Not sure why others don't feel the same way. > > Patches for the devmanual are welcome. Is that where the policy belongs? If so, shouldn't the council update it based on their decisions? "patches are welcome" doesn't fit every scenario. -Aaron
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On 3 Nov 2021, at 20:16, Rich Freeman wrote: > It probably would be good to get these policies documented someplace > OTHER than the council decision logs. I do remember the discussion > from the distant past but it is worth having it in a more prominent > place, especially since a one year stable update path is not going to > happen by accident. +1 > I was thinking that it matters way more that @system is updatable than > world in general, since @system can be used to bootstrap everything > else. However, I think this distinction really doesn't make much of a > difference. If your system can't be smoothly updated, it is unlikely > to be due to some leaf package like a browser/MUA/etc. Most likely it > is due to a widely-used dependency. > So, by all means require @world to be updatable, but I think that if > you focus on the packages in @system you'll basically get the rest for > free. This isn't quite true because it's very possible that plenty of things will have e.g. subslot deps on @system packages and therefore are holding them back if a change happens (you want to rebuild everything together). > EAPI 8 came up in a later email and to consolidate replies I'll just > say that the issue isn't so much adopting EAPIs in newer packages, but > the rush to tidy up old ones that creates the problems. Right. I think we could really try to just not cleanup so aggressively unless we know there's some nasty < dep in the ebuild. There's another really good reason for this: stabilisation and such doesn't catch everything, and you might find you just got upgraded to a newly-stabled ebuild which doesn't work, and now you have to fight to downgrade because cleanup was immediately done! > Having QA tools detect this would be ideal, but right now they could > only reliably detect things like newer EAPIs in @system. Since we > don't require putting @system dependencies in packages there is no way > for a QA tool to tell what is or isn't needed to update portage. Then > you have more complex situations like PYTHON_TARGETS, and probably > others as well. I had one host that struggled a bit with the xcrypt > update for some reason (some weird preserved libs issue or something - > libcrypt was still showing up as owned by glibc after updating it and > I had to override collisions to get xcrypt to install). When > upgrading a system that is completely up to date requires careful > following of news items it is going to be painful to execute a whole > bunch of updates at once. (We did work very hard on this to make it as smooth as possible and we've also dropped the workaround which caused the intentional collision (which we mentioned in the news item + glibc's pkg_postinst) which Portage should've ignored with default FEATURES b/c the file was orphaned, but it should be better now.) best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On 3 Nov 2021, at 22:15, Joshua Kinard wrote: > Actually, it is possible to manage dependency errors like those. It just > takes a *lot* of elbow grease, and and long, long time time. Especially if > you have museum-grade hardware that these errors are happening on. > > For Perl, I've usually just uninstall everything under virtual/* first, then > try to let it upgrade. Sometimes that "unsticks" something in perl-core > enough to let the upgrades apply, pulling back in any needed items from > virtual/. If that doesn't solve the problem enough to let emerge do an > upgrade cycle, I'll try using just the @system target, or start yanking > things out from perl-core/* one-by-one until emerge shuts up and does what > it is told. For what it's worth, you really really shouldn't need to do this. Perl is great at consuming backtracking cycles (largely because of all of the || ( ... ) deps in the virtuals) and cranking that up helps a lot. But something which we're not really clear enough on is that users should genuinely never have to use emerge -C / --unmerge. Trying just @system shouldn't be needed either and is in fact likely to be more problematic: https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_when_I_attempt_to_upgrade_a_single_package.3F > Also, *always* check for libperl-www being in the package list. It's > usually sucked in by way of dev-util/intltool and is responsible for ~35-40 > perl packages alone being pulled in. If that's in the list, try > uninstalling just that one, then run a depclean to remove all of its > dependencies and then see if the upgrade will work. If the upgrade tries to > drag intltool or libperl-www back in, use --exclude to hold it out for later. > Aye, we fixed eudev to not need it anymore and there's an avahi bug for the same I'll look at shortly. > That all said, am I alone in thinking that the way Portage emits error > messages about dependency resolution problems is extremely messy and > border-line unreadable at times? The current way it outputs depgraph errors > feels like something I'd expect from a --debug switch. We've got a > reputation for being playful and colorful on the command line with our > tooling, so I would wonder if that depgraph output couldn't be made to > looknicer? > Yeah, I think one of our biggest weaknesses is that there's usually a LOT of output and figuring out what matters isn't easy. A good rule of thumb is that the "most fatal" error is _usually_ at the bottom but this isn't always true. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On 3 Nov 2021, at 15:03, Thomas Deutschmann wrote: > > Hi, > > it is currently not possible to smoothly run a world upgrade on a 4 months > old system which doesn't even have a complicated package list: > [snip] > > This is not about finding solution to upgrade the system (in this case it was > enough to force PYTHON_TARGETS=python3_8 for portage). This is about raising > awareness that Gentoo is a rolling distribution and that we guarantee users > to be able to upgrade their system when they do world upgrades just once a > year (remember: in my case the last world upgrade is just 4 months old!). If > they cannot upgrade their system without manual intervention, we failed to do > our job. > > Situations like this will disqualify Gentoo for any professional environment > like this will break automatic upgrades and you cannot roll individual fixes > for each possible situation via CFM tools like Salt, Ansible, Puppet or Chef. > > It would be very appreciated if everyone will pay more attention to this in > future. We can do better. In most cases we can avoid problems like this by > keeping older ebuilds around much longer for certain key packages to help > with upgrades. I agree wholeheartedly with this and thank you for raising it. ## Remark on some previous discussion First, let me just mention that I think it's been on some of our minds but we need to go a bit further with formalising matters. It was brought up at the end of the September 2021 council meeting as a footnote: ``` [21:16:56] <@sam_> I'd like to consider "upgrade lifcycles" at some point but I don't have notes ready for now. Mainly just about formalising efforts to support upgrades for X period and to try document a procedure for e.g. new EAPI versions and bootstrap packages not having new EAPIs for a while, and such. [21:17:09] <@sam_> So, no, not right now, but I'd welcome any thoughts post-meeting while I consider it more [21:17:33] <@sam_> The gist is to have a checklist so that we don't "get excited" like with EAPI 8 and end up making upgrades hard for people [21:17:43] <@sam_> I think the GLEP we recently approved helps with that ``` I started working on some notes too on possible improvements: https://wiki.gentoo.org/wiki/User:Sam/TODO#Improving_upgrades. (I wanted to mention all of this here because it's easy to lose track of e.g. council meeting references on a topic, so it's easy to find it in the thread now.) ## Summary of the two common cases Now, in terms of the common issues regarding upgrades, I think we have two (to be clear, not trying to "fix your problem" -- just bring to bear some of the support experience I've had from #gentoo and so on): 1) World upgrades which can't complete due to new EAPIs (one's Portage lacks support for e.g. EAPI 8 and hence cannot read ebuilds) I'm open to more broad measures about usage of new EAPIs in ~arch / stable (say, e.g. the first Portage supporting EAPI N should sit in ~arch for 4/6/??? months before any ebuilds should use it?), but I think this is a drastic measure we might be able to avoid. Let's keep it in mind in case we do need it though. My general thinking on this is that it doesn't matter _too much_(?) as long as one can upgrade Portage without hassle. A lot of our users seem to know to try upgrade Portage if they can't upgrade their system due to new EAPIs, but they then fall down due to cryptic errors (see my next point). We could also improve the "unknown EAPI" error if necessary to make this more clear. TL;DR: We might be able to leverage a more drastic option, but my hope is we can avoid any direct action in handling 1) if we deal with the next point I'm about to make (2)). 2) Portage often can't upgrade itself when there's "pending global PYTHON_TARGETS changes" (e.g. when we change the default value of PYTHON_TARGETS in the profiles (like from Python 3.8 to Python 3.9)) This one is far trickier. I've started documenting common hacks/methods at https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution which has been rather useful in #gentoo and on the forums (it's been nice to see links on those and other similar pages pop up on /r/gentoo). Portage is written in Python and has dependencies in Python. A lot of them are optional (which is why in the wiki page I linked to, I suggest emerge --syncing and then turning off USE=rsync-verify temporarily to reduce dependencies), but I don't think this is particularly comforting to a user who just wants to upgrade Portage. They don't necessarily realise they need to toggle one or *several* flags on Portage to make it work. dilfridge has been advocating for some time that we try look at some form of a "static Portage" copy (possibly vendoring/bundling all Python dependencies) to completely decouple the Portage ebuilds from the Python eclasses other than needing a (modern) Python 3 interpreter. [I've filed a bug for this here: https://bugs.gentoo.org/821511].
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 3, 2021 at 2:50 PM Andreas K. Huettel wrote: > > Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller: > > > On Wed, 03 Nov 2021, Andreas K Huettel wrote: > > > > > The mistake was to allow the use of EAPI=8 too early. In the future, > > > we should have a new EAPI supported by portage for at least some > > > months before the EAPI is even used in the main tree. Not even > > > speaking about stable here. > > > > I tend to disagree. Adding an ebuild with a new EAPI cannot break > > anything, because it will simply be invisible to old package managers. > > Except that you need to keep track of version dependencies across the whole > tree. > > So, yes, this is in principle correct, and in practice with our current > tooling more or less impossible to do reliably. I think the obvious easy solution here is to run a CI that is using older stuff, and report problems when commits break that. It's less clear what to do about it though; the problems Whissi raised.. it's not like we didn't know about them (they were known), but we chose not to do anything about it? Or we learned about them too late (and figured the majority of users had seen it; so fixing them was not necessary?) -A > > [Part of the output Whissi pasted was (more or less) that a Perl upgrade > required a rebuild of Perl modules. Unfortunately, even a single one that > is not available for rebuild makes the emerge bail out.] > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller: > > On Wed, 03 Nov 2021, Andreas K Huettel wrote: > > > The mistake was to allow the use of EAPI=8 too early. In the future, > > we should have a new EAPI supported by portage for at least some > > months before the EAPI is even used in the main tree. Not even > > speaking about stable here. > > I tend to disagree. Adding an ebuild with a new EAPI cannot break > anything, because it will simply be invisible to old package managers. Except that you need to keep track of version dependencies across the whole tree. So, yes, this is in principle correct, and in practice with our current tooling more or less impossible to do reliably. [Part of the output Whissi pasted was (more or less) that a Perl upgrade required a rebuild of Perl modules. Unfortunately, even a single one that is not available for rebuild makes the emerge bail out.] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On Wed, 03 Nov 2021, Andreas K Huettel wrote: > The mistake was to allow the use of EAPI=8 too early. In the future, > we should have a new EAPI supported by portage for at least some > months before the EAPI is even used in the main tree. Not even > speaking about stable here. I tend to disagree. Adding an ebuild with a new EAPI cannot break anything, because it will simply be invisible to old package managers. There won't be a problem unless you _remove_ ebuilds that are part of the upgrade path. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On Wed, 03 Nov 2021, Aaron Bauman wrote: > I love digging through old council logs to find "policy" > Not sure why others don't feel the same way. Patches for the devmanual are welcome. signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 3, 2021 at 1:14 PM Ulrich Mueller wrote: > > > On Wed, 03 Nov 2021, John Helmert wrote: > > >> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > >> | > >> | Upgrade path for old systems > >> | > >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a > >> | stable system that hasn't been updated for one year. > > > Does "upgrade path" imply a simple world upgrade is all that should be > > necessary to upgrade the system? I wouldn't interpret it this way. > > That a "simple world upgrade" was meant is very clear from the full > meeting log, and from the log of the previous 2009-10-12 meeting (open > floor section). > It probably would be good to get these policies documented someplace OTHER than the council decision logs. I do remember the discussion from the distant past but it is worth having it in a more prominent place, especially since a one year stable update path is not going to happen by accident. I was thinking that it matters way more that @system is updatable than world in general, since @system can be used to bootstrap everything else. However, I think this distinction really doesn't make much of a difference. If your system can't be smoothly updated, it is unlikely to be due to some leaf package like a browser/MUA/etc. Most likely it is due to a widely-used dependency. So, by all means require @world to be updatable, but I think that if you focus on the packages in @system you'll basically get the rest for free. EAPI 8 came up in a later email and to consolidate replies I'll just say that the issue isn't so much adopting EAPIs in newer packages, but the rush to tidy up old ones that creates the problems. If you have v1/2/3 of a package stable and in the repo, and v3 uses an unsupported EAPI, and v1 is installed, I think portage will (or at least ought to) offer an upgrade from v1 to v2 - it should just not see v3 or consider it in the depgraph. Of course keeping around old versions might require dealing with security issues/etc that impact them. An alternative would be of course to just avoid EAPI updates on @system for a little while, or at least the parts of @system that portage needs to upgrade. Having QA tools detect this would be ideal, but right now they could only reliably detect things like newer EAPIs in @system. Since we don't require putting @system dependencies in packages there is no way for a QA tool to tell what is or isn't needed to update portage. Then you have more complex situations like PYTHON_TARGETS, and probably others as well. I had one host that struggled a bit with the xcrypt update for some reason (some weird preserved libs issue or something - libcrypt was still showing up as owned by glibc after updating it and I had to override collisions to get xcrypt to install). When upgrading a system that is completely up to date requires careful following of news items it is going to be painful to execute a whole bunch of updates at once. Maybe another path would be to mark milestone repositories for the last year that are easy to update in sequence. So if you have an update that requires manual care, you could mark a milestone just before that update which is easy to get to, and then another one after the update (ideally right before the next difficult update). This would just be a snapshot of portage or a git commit reference, and along with that a commitment to maintain distfiles/etc if they aren't hosted in reliable places (ie patches/etc in devspace). Another option might be to have collections of binary packages at key milestones. Sure, they won't be built to a user's specification, but if you have a year old system you could use them to quickly bootstrap it up to something more recent, and then an emerge will rebuild anything that has the wrong USE flags/etc and to bring the system completely up to date. You could even just use those binary packages as a sort of release-based version of the distro. Just some things to consider. -- Rich
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 16:03:37 CET schrieb Thomas Deutschmann: > Hi, > > it is currently not possible to smoothly run a world upgrade on a 4 > months old system which doesn't even have a complicated package list: > [snip] Yup. We know. It's actually way worse than you describe [*] and was noticed already quite some time ago. Unfortunately this is a situation that can IMHO not be easily fixed, and we can only strive to do it better next time. The mistake was to allow the use of EAPI=8 too early. In the future, we should have a new EAPI supported by portage for at least some months before the EAPI is even used in the main tree. Not even speaking about stable here. From there on all the trouble cascades. And no, disallowing a new EAPI for only a part of the tree does not help. (Which part?) An alternative, which we should seriously consider (and which I've been advocating for several months now) is to make Portage more robust, so it can more easily upgrade itself, and keep the Portage ebuild at old EAPI. This means, * making Portage independent of the python eclasses, so it runs as long as any python3 interpreter exists * and bundling all Python dependencies it needs for functioning in it [*] Of course there are ways around this to upgrade the system. However, that is not the point. It should work out of the box. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
211103 John Helmert III wrote: > An "upgrade path" to me sounds like not just a world update, > but also includes other stuff > that might be necessary to get a system fully updated, > like temporarily setting PYTHON_TARGETS to upgrade a package. > A system without an upgrade path would seem to be a system > where there is no way to upgrade it without reinstalling, > which you seem to be asserting is the case for this system. The Council resolution doesn't seem to have been well-thought-out : why "1 year" & however could anyone measure that ? what counts as an upgrade path ? -- problem-free or possible with some work ? The basic problem is that Portage isn't capable of resolving all conflicts. In order to do that, a great deal more programing work would be necessary, which the hard-working volunteer developers are unlikely to have time for. That means that users must put in a bit of their own time & use some good sense based on experience to find a path for themselves. People who can't do that shouldn't try using Gentoo. I've been using Gentoo on all my machines for > 18 yr now & have never tried to do 'emerge world' without '-pv', and I've almost always been able to find my way thro' fairly quickly. I have updated year-old systems occasionally with success. You have to make a list of the pkgs which need updating -- either by 'emerge -pv world' or via 'eix-sync' output -- , then work thro' the list updating a few pkgs at a time, starting of course with the most fundamental, eg system pkgs. That way, problems are usually easily identified & often simply disappear when you put them aside & emerge further pkgs. There are some regular blockages which require unmerging a set of pkgs -- eg notoriously the Qt pkgs -- , then remerging all of them together. Some problem pkgs can simply be left as they are & everything still works. If you expect Portage to do all the work for you in the background, it isn't going to succeeed. HTH -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote: > > On Wed, 03 Nov 2021, Rich Freeman wrote: > > > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann > > wrote: > >> > >> This is not about finding solution to upgrade the system (in this case > >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is > >> about raising awareness that Gentoo is a rolling distribution and that > >> we guarantee users to be able to upgrade their system when they do world > >> upgrades just once a year (remember: in my case the last world upgrade > >> is just 4 months old!). If they cannot upgrade their system without > >> manual intervention, we failed to do our job. > > > Do we have this "guarantee" documented somewhere? I thought I've > > heard six months tossed around. You say one year. It seems > > reasonable to have some sort of guideline like this and try to stick > > with it, at least for @system. > > We do. Summary of 2009-11-09 Council meeting: > I love digging through old council logs to find "policy" Not sure why others don't feel the same way. > | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > | > | Upgrade path for old systems > | > | Vote (unanimous): The ebuild tree must provide an upgrade path to a > | stable system that hasn't been updated for one year. > | > | Action: leio will start a discussion on gentoo-dev on if and how to > | support upgrading systems that are outdated more than a year.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On Wed, 03 Nov 2021, John Helmert wrote: >> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt >> | >> | Upgrade path for old systems >> | >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a >> | stable system that hasn't been updated for one year. > Does "upgrade path" imply a simple world upgrade is all that should be > necessary to upgrade the system? I wouldn't interpret it this way. That a "simple world upgrade" was meant is very clear from the full meeting log, and from the log of the previous 2009-10-12 meeting (open floor section). Apparently the problem is neither new (see above, it existed in 2009) nor is it uncommon. In fact, the Gentoo e.V. will have a workshop about this topic on 2021-11-20 [1]. Ulrich [1] https://gentoo-ev.org/news/online-workshops-2021/ signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:51:49PM +0100, Thomas Deutschmann wrote: > On 2021-11-03 17:44, John Helmert III wrote: > >> | Upgrade path for old systems > >> | > >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a > >> | stable system that hasn't been updated for one year. > > Does "upgrade path" imply a simple world upgrade is all that should be > > necessary to upgrade the system? I wouldn't interpret it this way. > > Could you please share your interpretation? I wonder how you can agree > on an upgrade path but still require manually hacking to get a system > up-to-date. That is basically the definition of "upgrade path"... Sure. An "upgrade path" to me sounds like not just a world update, but also includes other stuff that might be necessary to get a system fully updated, like temporarily setting PYTHON_TARGETS to upgrade a package. A system without an upgrade path would seem to be a system where there is no way to upgrade it without reinstalling, which you seem to be asserting is the case for this system. 13:36 <@Whissi> Nice. Due to some people rushing to EAPI8 and remove old ebuilds they broke the guarantee to update systems at least once a year again. Congratulations! http://dpaste.com/AD87YKY62 13:36 <+sam_> your issue is to do with python targets changing: PYTHON_TARGETS="python3_8" emerge -v1 portage should work 13:37 <@Whissi> As you can see, it doesn't work. 13:37 <+sam_> that's not what you ran though? 13:37 <+sam_> see https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution 13:37 <@Whissi> http://dpaste.com/7RYRJD72H 13:38 <+sam_> you're not forcing the old PYTHON_TARGETS? 13:39 <@Whissi> No, http://dpaste.com/7V727USW4 13:39 <+sam_> but i'm saying you should 13:39 <+sam_> (not that you should _have_ to) 13:39 <+sam_> temporarily do it once on the command line 13:39 <+sam_> it is enough to get portage upgraded 13:39 <+sam_> we do it often in #gentoo Based on this snippet from #gentoo-mozilla, it does seem like there is a way forward for this system. signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On 2021-11-03 17:44, John Helmert III wrote: | Upgrade path for old systems | | Vote (unanimous): The ebuild tree must provide an upgrade path to a | stable system that hasn't been updated for one year. Does "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way. Could you please share your interpretation? I wonder how you can agree on an upgrade path but still require manually hacking to get a system up-to-date. That is basically the definition of "upgrade path"... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote: > > On Wed, 03 Nov 2021, Rich Freeman wrote: > > > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann > > wrote: > >> > >> This is not about finding solution to upgrade the system (in this case > >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is > >> about raising awareness that Gentoo is a rolling distribution and that > >> we guarantee users to be able to upgrade their system when they do world > >> upgrades just once a year (remember: in my case the last world upgrade > >> is just 4 months old!). If they cannot upgrade their system without > >> manual intervention, we failed to do our job. > > > Do we have this "guarantee" documented somewhere? I thought I've > > heard six months tossed around. You say one year. It seems > > reasonable to have some sort of guideline like this and try to stick > > with it, at least for @system. > > We do. Summary of 2009-11-09 Council meeting: > > | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > | > | Upgrade path for old systems > | > | Vote (unanimous): The ebuild tree must provide an upgrade path to a > | stable system that hasn't been updated for one year. Does "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way. > | Action: leio will start a discussion on gentoo-dev on if and how to > | support upgrading systems that are outdated more than a year. signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
> On Wed, 03 Nov 2021, Rich Freeman wrote: > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann wrote: >> >> This is not about finding solution to upgrade the system (in this case >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is >> about raising awareness that Gentoo is a rolling distribution and that >> we guarantee users to be able to upgrade their system when they do world >> upgrades just once a year (remember: in my case the last world upgrade >> is just 4 months old!). If they cannot upgrade their system without >> manual intervention, we failed to do our job. > Do we have this "guarantee" documented somewhere? I thought I've > heard six months tossed around. You say one year. It seems > reasonable to have some sort of guideline like this and try to stick > with it, at least for @system. We do. Summary of 2009-11-09 Council meeting: | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt | | Upgrade path for old systems | | Vote (unanimous): The ebuild tree must provide an upgrade path to a | stable system that hasn't been updated for one year. | | Action: leio will start a discussion on gentoo-dev on if and how to | support upgrading systems that are outdated more than a year. signature.asc Description: PGP signature
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann wrote: > > This is not about finding solution to upgrade the system (in this case > it was enough to force PYTHON_TARGETS=python3_8 for portage). This is > about raising awareness that Gentoo is a rolling distribution and that > we guarantee users to be able to upgrade their system when they do world > upgrades just once a year (remember: in my case the last world upgrade > is just 4 months old!). If they cannot upgrade their system without > manual intervention, we failed to do our job. Do we have this "guarantee" documented somewhere? I thought I've heard six months tossed around. You say one year. It seems reasonable to have some sort of guideline like this and try to stick with it, at least for @system. (I had a painful update on a container that was about six months old a little while ago - I just did updates from git checkouts (which isn't guaranteed to work due to distfiles issues). Obviously troubleshooting a container where a rollback is a one-liner is a lot easier, but progressive updates also tend to require a lot of semi-redundant updates.) -- Rich
