On Fri, Jun 12, 2020 at 10:38 AM 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: > > > > > > 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. > > > > > > > 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?
Once you run chroot you're in the same environment you get when you boot the system normally. It would fix a kernel problem, but not userspace problems. Some people extract a stage3 over their system. That is a very messy solution to be avoided if possible, but that is one way to go about it if you know what you're doing. You'll end up with a ton of orphaned files that could cause problems later. Just doing a clean install and migrating the stuff you want to keep would be much cleaner as suggested in Joost's later reply. As far as the tagging proposal goes, such a thing is definitely possible. The main issues are: 1. Somebody needs to care enough to do it. You'd probably want at least a bit of QA/testing around this. Also, upgrades might still need to be incremental. 2. We need a better solution for hosting non-upstream large files. There are no guarantees that a SRC_URI in an ebuild that was removed from the repo six months ago still works. That applies to upstream too, but it mostly applies to thinks like large Gentoo-hosted patches. We don't necessarily keep them around after the package is gone, and the mirrors purge their copies automatically. If you want to go back in time reliably these need to be version-controlled/etc. There are a lot of things that could be done in this general direction, such as binary repositories. Mostly the issue is that the current approach scratches just about everybody's itch so nobody wants to bother building something in addition to it... -- Rich
