On Saturday 26 April 2008, Mark Knecht wrote: > I don't buy that it's my issue created by a long time between > updates. I could turn on any machine that's sitting in a junk heap or > back room somewhere. It hasn't been powered up in a long time. I log > in and want to figure out what's in front of me with respect to > updates. I type emerge sync and portage deletes files. to me that's > just wrong.
Mark, This might be worth discussing. I know you said "enough of this" later on but enough users run into conceptually similar issues to make it worth while. Examples: someone needs a specific kernel version for some hardware and it goes away from portage or weird video cards where only ATIs magic from 2005 actually works. First, let's look at the real source of the problem: using rsync to download the tree. To know what will change or what's new portage needs a new tree, and there is no summary for that. It really needs two trees to run a diff against and it has to be done locally - the rsync server is clueless about what you currently have. So basically to tell you what will change, portage has to have a new tree which nukes the old stuff... One could write a dual-portage thingy that replicates what you have then does emerge --sync, and also has an --undo fetaure for just in case. Ughh. One must take account of the portage db, the metacache and other bits as well. So how about something that creates overlays for you? As a wrapper to emerge? It could have options to convert various bits of the current system to private overlays, and generate a decent cache to speed things up (the current state of affairs will not cache a local overlay by default so it's really slow). I'm thinking of these things: - Install every currently installed ebuild to an overlay, or install specific ebuilds or specific categories to an overlay. - Copy an installed ebuild and it's entire installed DEPEND tree to an overlay - this is for cases where <arb_lib> is not in world but is required as a deep dependency of something that is. The user will probably not be aware of this dependency and not having that ebuild will break stuff. - Copy an entire profile to an overlay - Copy everything in an installed ebuild's SRC_URI (or all installed ebuilds) to a different DISTDIR for safety (think ATI driver downloads or kernels here) - Remove old ebuilds and profiles from the overlay that you have since upgraded - Possibly more Such a script would do the backup you wished you had done for your folks, but only the bits you had installed (not everything), then run emerge. You get a good compromise between you needing old stuff to be around and the dev's perfectly reasonable desire to not have to support old stuff not in common use. It could be implemented one of these ways: - a new feature to portage - highly unlikely considering the fear and dread that comes with modifying portage in it's current state - a new feature to paludis - this might be possible as I believe paludis' code design is quite sane - a wrapper around emerge (easiest and most likely to benefit the largest numbers if interested users) -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
