* [gentoo-portage-dev] RFC on a "slot" update command
@ 2003-11-04 14:57 Thomas de Grenier de Latour
2003-11-04 15:57 ` Daniel Robbins
0 siblings, 1 reply; 2+ messages in thread
From: Thomas de Grenier de Latour @ 2003-11-04 14:57 UTC (permalink / raw
To: gentoo-portage-dev
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@gentoo.org mailing list
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-11-04 15:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-04 14:57 [gentoo-portage-dev] RFC on a "slot" update command Thomas de Grenier de Latour
2003-11-04 15:57 ` Daniel Robbins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox