Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-portage-dev
Navigation:
Lists: gentoo-portage-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-portage-dev@g.o
From: Thomas de Grenier de Latour <degrenier@...>
Subject: RFC on a "slot" update command
Date: Tue, 4 Nov 2003 15:57:20 +0100
Hi,

I'm not sure this list is really alive, and if users' posts are welcome,
but anyway, let's try...


Updating gvim yesterday I had a compilation failure similar to this one:
http://bugs.gentoo.org/show_bug.cgi?id=32589

It was because I had also updated dev-lang/ruby before, and in the 1.8.x
branch I use, slot changed from 0 to 1.8, and so the previous version
remained installed more or less breaking the new one. Sure, there
was a postinst warning about this in the updated ruby ebuild, but it is
well known that we always miss the important ones during a world update.
So what I see here is a bug, where updating world can break a package
(an important one for people who use ruby for some administration
scripts). But this slot change was useful from the ruby-dev point of
view, and they made no real "mistake" here I think.

Imho, the real issue is that portage doesn't handle packages reslotting.
If a package change its slot, then you end up with several installed
versions but if you do manual cleanup. A simple solution would be to
allow developers to express their reslotting operations in portage
updates files (I mean the "xQ-200y" files), exactly like when they
move/rename a package. From portage point of view, this two operations
are equally important: if no db update operation is done, then a ghost
packages will stay on the system, sometimes with bad consequences.

I've suggested this portage feature some time ago:
http://bugs.gentoo.org/show_bug.cgi?id=27965

Taking the ruby package as an example, the update command could have
been something like this:
  "slot  dev-lang/ruby-1.8*  dev-lang/ruby-1.8*  1.8"
This way, after this update applied by "emerge sync", my db would have
been ready to accept a clean ruby update, meaning that the previous
installed version would have been unmerged by autoclean.  

I don't ask for comments on the patch I had submitted in the above
cited bug report (because it is probably incomplete and outdated), but I
would like to have your opinion on the idea itself. If you think an
updated patch have a chance to reach portage, then I will work on it.

Thanks,

-- 
TGL.

--
gentoo-portage-dev@g.o mailing list

Replies:
Re: RFC on a "slot" update command
-- Daniel Robbins
Navigation:
Lists: gentoo-portage-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
GLEP 14 progress report
Next by thread:
Re: RFC on a "slot" update command
Previous by date:
GLEP 14 progress report
Next by date:
Re: RFC on a "slot" update command


Updated Jun 17, 2009

Summary: Archive of the gentoo-portage-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.