On 12 June 2020 16:38:28 CEST, Michael <[email protected]> wrote: >On Friday, 12 June 2020 15:00:25 BST Jack wrote: >> On 6/12/20 9:49 AM, Rich Freeman wrote: >> > On Fri, Jun 12, 2020 at 4:00 AM n952162 <[email protected]> wrote: >> >> On 2020-06-12 08:40, n952162 wrote: >> >>>> BTW, is it becoming clear why it is best to update Gentoo at >least >> >>>> ever few months? :) >> >>> >> >>> Well, yes, but it's really pretty onerous. If you have gentoo in >> >>> embedded systems, you've got to spend considerable administrative >effort >> >>> in each one just maintaining the status quo. >> >>> >> >>> I mean, there's no competition to gentoo, of course. But a >design goal >> >>> could be to have a one-step sync, of some sort. >> >> >> >> Maybe one way to work in that direction would be to have regular - >say, >> >> yearly - "releases", kind of like other distributions do, but on >an >> >> ebuild basis, re-establishing a common base point. >> > >> > Well, you already can just use a snapshot of the repository from >any >> > date in time, though things like patches might not be mirrored any >> > longer so that isn't a perfect solution. >> > >> > Ultimately if there was enough interest in something like this the >> > solution would probably be another distro that just repackages >Gentoo >> > in a release-based format. Release-based distros have their pros >and >> > cons, but they're definitely a better fit for some problems. >> > >> > One of the issues with Gentoo is that it is fairly niche and so you >> > don't have the manpower to support 47 forks. With Debian you have >a >> > bazillion derivatives - half of them are just bundling a different >set >> > of default packages. Ubuntu has a Desktop and Server version of >the >> > distro, and they also have flavors for various desktop >environments. >> > Gentoo basically has just barely enough manpower to support having >> > Gentoo. We try to accommodate as much choice as possible in how it >> > gets used which is why this model works as well as it does. >However, >> > we can't support having a Gentoo flavor that is GPL-only, or >GPL-free, >> > or FOSS-only, or no-systemd-in-the-repo, or initial install >optimized >> > for people who read braille. You can actually tailor Gentoo >towards >> > just about any of those directions with some config file tweaks, >but >> > you can't just pick the one of 300 iso images that most closely fit >> > your needs and run the autoinstaller and forget about it. >> >> What about some sort of tagging? Not bundling or packaging, just >> occasional (quarterly?) labels, with a matrix indicating how >difficult >> it would be to upgrade. A hint to folks who tend to update less >often >> than they should. A "heads up" that things added or upgraded in the >> past quarter are going to be very difficult to do if you are starting >> with something more than three/five/...? quarters older than that. >Of >> course, I suppose if you read the news items as they are released, >then >> you should have a pretty good idea of which of them are likely to >bite >> you if you wait too long. > >Perhaps I misunderstand this, but isn't it as simple as booting off a >LiveCD/ >USB, chrooting, changing profiles, cleaning up world file and letting >rip with >a full 'emerge -e' @system, followed by @world for good measure?
It might work when moving fron 13.0 to 17.0. But 17.1 required a seperate tool that actually migrated libraries around the filesystem. I doubt it can be handled reliably that way. I would rebuild from scratch, copying any config files across. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
