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:
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:
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.
firstname.lastname@example.org mailing list