Re: [gentoo-user] Would emerge --sync remove old profiles?

[Mark Knecht]

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 <alan.mckinnon@×××××.com> 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@l.g.o mailing list