From: Thomas de Grenier de Latour <degrenier@easyconnect.fr>
To: gentoo-portage-dev@gentoo.org
Subject: [gentoo-portage-dev] RFC on a "slot" update command
Date: Tue, 4 Nov 2003 15:57:20 +0100 [thread overview]
Message-ID: <20031104155720.3bd68726.degrenier@easyconnect.fr> (raw)
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
next reply other threads:[~2003-11-04 14:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-04 14:57 Thomas de Grenier de Latour [this message]
2003-11-04 15:57 ` [gentoo-portage-dev] RFC on a "slot" update command Daniel Robbins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031104155720.3bd68726.degrenier@easyconnect.fr \
--to=degrenier@easyconnect.fr \
--cc=gentoo-portage-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox