Hi Alan, Thanks for the reply. Also, up front, I'm thinking that my tone is somehow being misinterpreted. I'm not at all high energy about this. I'm worried now it's not coming across the way I'm feeling about this. Low key. Low stress. Just looking to make things better in the future. Nothing more. I hope folks understand that. If not I apologize as it's hard to convey energy.
On Sat, Apr 26, 2008 at 1:00 PM, Alan McKinnon <[EMAIL PROTECTED]> wrote: > 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 Really only because I don't want to drive people nuts or wear out my welcome. I'm interested in talking about it. Maybe something good will come along one day because of the conversation. > 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... OK, so rsync itself is where the real magic is that exposes what I consider a weakness? Good info. > > 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? This is, I think, exactly what I've been suggesting, assuming portage or the wrapper can get in between rsync and my personal data. I consider my copy of portage data 'personal data' but then again I have to take responsibility for using a program that erases my data. Any alternatives to rsync? ;-) (Really, just kidding!) > 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 > Yeah, sounds like lots of work, and in my mind probably not worth the effort. I'm thinking of something as conceptually simple (if possible) as emerge --sync-test which instead of actually syncing would just tell me what is going to be added and/or removed from my copy of the portage tree. I could then look look for any overlaps between that data and the output of eix -Ic and move them to my overlay by hand. Maybe the script you are speaking of could look for the overlaps, etc. using eix -Ic itself? Just an idea. Again, the ONLY things I would be interested in saving are things I currently have installed. If it's not installed then it's of no immediate interest to me. > 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) > It sounds like plaudis might be a place to try to find long term support for an idea like this. I've not used it so I'll check it out. That said you're comments about about it backing up only the little bits I had installed is what seems the most useful to me, and possibly to others also. If that back is a move operation to my obsolete overlay directory then everything still works even though it's no longer in portage. Sounds great. Thanks, Mark -- gentoo-user@lists.gentoo.org mailing list
