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

[Mark Knecht]

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 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,
   I've been playing with eix-test-obsolete. I think possibly it could
help in this area.

   The machine is completely clean with emerge world, emerge -DuN
world, emerge --depclean and revdep-rebuild. After using
eix-test-obsolete for awhile and cleaning things up it now correctly
shows two packages currently on my machine for which there are no
matching entries in the database:

lightning ~ # eix-test-obsolete

No non-matching entries in /etc/portage/package.keywords.
No non-matching entries in /etc/portage/package.mask.
No non-matching entries in /etc/portage/package.unmask.
No non-matching or empty entries in /etc/portage/package.use.
No non-matching or empty entries in /etc/portage/package.cflags.
The following installed packages are not in the database:

net-im/gaim
net-print/hpijs
--

No redundant entries in /etc/portage/package.keywords (or test switched off).
No redundant entries in /etc/portage/package.mask (or test switched off).
No redundant entries in /etc/portage/package.unmask (or test switched off).
No redundant entries in /etc/portage/package.use (or test switched off).
No redundant entries in /etc/portage/package.cflags (or test switched off).
No uninstalled entries in /etc/portage/package.keywords (or test switched off).
No uninstalled entries in /etc/portage/package.mask (or test switched off).
No uninstalled entries in /etc/portage/package.unmask (or test switched off).
No uninstalled entries in /etc/portage/package.use (or test switched off).
No uninstalled entries in /etc/portage/package.cflags (or test switched off).
All installed versions of packages are in the database (or test switched off).
lightning ~ # eix -I gaim
No matches found.
lightning ~ # eix -I hpijs
No matches found.
lightning ~ # emerge -Cp gaim

>>> These are the packages that would be unmerged:

 net-im/gaim
    selected: 1.5.0
   protected: none
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

lightning ~ # emerge -Cp hpijs

>>> These are the packages that would be unmerged:

 net-print/hpijs
    selected: 1.7.1
   protected: none
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

lightning ~ #

   Here's my idea: How hard would it be to have eix-test-obsolete
verify against the global database instead of the local database? If I
ran it that way  *before* I ran emerge --sync then it would tell me
effectively which packages would be removed after syncing. I could
then move what I need to move by hand, run emerge --sync, and I'd
still be clean because I've saved my files into my private overlay
before the sync operation can delete them.

   If an enhancement like that is fairly simple - I have no idea -
then that would be a great start. Still, it's not protection against
the root cause of the problem, but it's a simple way to see ahead of
time what might happen.

Cheers,
Mark
-- 
gentoo-user@l.g.o mailing list