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 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
--
[email protected] mailing list
