> On 3 Nov 2021, at 20:16, Rich Freeman <ri...@gentoo.org> 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
