| 1 |
Hi, |
| 2 |
|
| 3 |
I'm not sure this list is really alive, and if users' posts are welcome, |
| 4 |
but anyway, let's try... |
| 5 |
|
| 6 |
|
| 7 |
Updating gvim yesterday I had a compilation failure similar to this one: |
| 8 |
http://bugs.gentoo.org/show_bug.cgi?id=32589 |
| 9 |
|
| 10 |
It was because I had also updated dev-lang/ruby before, and in the 1.8.x |
| 11 |
branch I use, slot changed from 0 to 1.8, and so the previous version |
| 12 |
remained installed more or less breaking the new one. Sure, there |
| 13 |
was a postinst warning about this in the updated ruby ebuild, but it is |
| 14 |
well known that we always miss the important ones during a world update. |
| 15 |
So what I see here is a bug, where updating world can break a package |
| 16 |
(an important one for people who use ruby for some administration |
| 17 |
scripts). But this slot change was useful from the ruby-dev point of |
| 18 |
view, and they made no real "mistake" here I think. |
| 19 |
|
| 20 |
Imho, the real issue is that portage doesn't handle packages reslotting. |
| 21 |
If a package change its slot, then you end up with several installed |
| 22 |
versions but if you do manual cleanup. A simple solution would be to |
| 23 |
allow developers to express their reslotting operations in portage |
| 24 |
updates files (I mean the "xQ-200y" files), exactly like when they |
| 25 |
move/rename a package. From portage point of view, this two operations |
| 26 |
are equally important: if no db update operation is done, then a ghost |
| 27 |
packages will stay on the system, sometimes with bad consequences. |
| 28 |
|
| 29 |
I've suggested this portage feature some time ago: |
| 30 |
http://bugs.gentoo.org/show_bug.cgi?id=27965 |
| 31 |
|
| 32 |
Taking the ruby package as an example, the update command could have |
| 33 |
been something like this: |
| 34 |
"slot dev-lang/ruby-1.8* dev-lang/ruby-1.8* 1.8" |
| 35 |
This way, after this update applied by "emerge sync", my db would have |
| 36 |
been ready to accept a clean ruby update, meaning that the previous |
| 37 |
installed version would have been unmerged by autoclean. |
| 38 |
|
| 39 |
I don't ask for comments on the patch I had submitted in the above |
| 40 |
cited bug report (because it is probably incomplete and outdated), but I |
| 41 |
would like to have your opinion on the idea itself. If you think an |
| 42 |
updated patch have a chance to reach portage, then I will work on it. |
| 43 |
|
| 44 |
Thanks, |
| 45 |
|
| 46 |
-- |
| 47 |
TGL. |
| 48 |
|
| 49 |
-- |
| 50 |
gentoo-portage-dev@g.o mailing list |
Archives