On Friday, 12 June 2020 15:44:05 BST n952162 wrote: > On 2020-06-12 16:38, Michael 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? > > Is -e a solution to my situation now? How is booting off a live media > better than an obsolete (or broken) one?
I think so. The LiveCD will possess an up to date toolchain you could use straight away. > And, BTW, is there a reason to do @system if that's a subset of @world? To rebuild with the latest gcc and work through any convoluted dependencies cutting across into world. It may not add anything, but other than rebuilding a few packages I don't think it will hurt.
signature.asc
Description: This is a digitally signed message part.
