Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 150361

Summary: Consistency in portage greedy behavior for update of all slots of package
Product: Portage Development Reporter: Michiel de Bruijne <m.debruijne>
Component: Core - Interface (emerge)Assignee: Portage team <dev-portage>
Status: VERIFIED FIXED    
Severity: enhancement CC: ansla80, carlo, caster, meax, news, oldium.pro, tom
Priority: High Keywords: InVCS
Version: 2.1   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=4698
https://bugs.gentoo.org/show_bug.cgi?id=152175
https://bugs.gentoo.org/show_bug.cgi?id=150251
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 147007    

Description Michiel de Bruijne 2006-10-07 02:32:27 UTC
As requested in bug #4698 a new bug for the request for consistency in portage greedy behavior.

Portage only supports greedy behavior in system and world set. Please make it consistent and enable greedy (by default) for every emerge -u <target>
Comment 1 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-10-07 03:36:22 UTC
Thanks for filling this one for me :)
Comment 2 Zac Medico gentoo-dev 2006-10-07 09:31:02 UTC
The current --update behavior is similar to --deep, except that it only tranverses to direct depenedencies and then stops.  It also implies the equivalent of --noreplace.

My main concern is that the meaning of the --update option will become too overloaded.  That's why I think greedy behavior should be enabled via a separate --greedy option (possibly with choices like --with-bdeps, but maybe that's not necessary).
Comment 3 Oldrich Jedlicka 2006-10-07 11:09:33 UTC
(In reply to comment #0)
> As requested in bug #4698 a new bug for the request for consistency in portage
> greedy behavior.
> 
> Portage only supports greedy behavior in system and world set. Please make it
> consistent and enable greedy (by default) for every emerge -u <target>

My personal meaning is that the update should update every slot - if you do not say different thing. 

Currently consistent behaviour is what any user expects.
Comment 4 Zac Medico gentoo-dev 2006-10-07 12:25:21 UTC
I suppose that it might make sense for --update to automatically imply greed behavior (pulling in all installed slots).  Can anyone think of a situation where greedy behavior would be unwanted with --update?  If not, I think we should go ahead and make it greedy.
Comment 5 Zac Medico gentoo-dev 2006-10-07 12:34:28 UTC
I think the way that we should for --update is as follows:

1) unspecific atoms are greedy
2) atoms that specify a version or slot are not greedy
Comment 6 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-10-07 12:39:34 UTC
(In reply to comment #4)
> Can anyone think of a situation
> where greedy behavior would be unwanted with --update?

Nope, unless somebody wants to update just the latest slot (but can't think of such a situation myself :), but then he should specify it explicitly.

(In reply to comment #5)
> I think the way that we should for --update is as follows:
> 
> 1) unspecific atoms are greedy
> 2) atoms that specify a version or slot are not greedy

Agreed.
Comment 7 Zac Medico gentoo-dev 2006-10-07 12:39:57 UTC
As an example, take `emerge -u >=jdk-1.4`.  Should that that be greedy and pull in all slots for versions >=1.4, or should it pull in just the highest version of jdk?
Comment 8 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-10-07 13:28:33 UTC
(In reply to comment #7)
> As an example, take `emerge -u >=jdk-1.4`.  Should that that be greedy and pull
> in all slots for versions >=1.4, or should it pull in just the highest version
> of jdk?

I would say, be consistent with what would such atom pull if it was in R/DEPEND variable of some ebuild during --deep update... which is now greedy, I suppose?
Comment 9 Zac Medico gentoo-dev 2006-10-07 13:37:33 UTC
(In reply to comment #8)
> I would say, be consistent with what would such atom pull if it was in R/DEPEND
> variable of some ebuild during --deep update... which is now greedy, I suppose?

Package dependencies are not and have never been greedy like that.  The only reason that I've made system and world greedy together is that they're internally bound together due to the fact that system packages are never added to the world file and the world file only stores unspecific atoms.
Comment 10 Oldrich Jedlicka 2006-10-07 13:51:27 UTC
(In reply to comment #7)
> As an example, take `emerge -u >=jdk-1.4`.  Should that that be greedy and pull
> in all slots for versions >=1.4, or should it pull in just the highest version
> of jdk?

I would say to have an update always greedy. This example then updates all installed slots (if the version in slot matches the criterion) plus installs newer slots (as usual). Like in world. This makes sense to me. 

If you want to update only one slot, you should say which slot.
Comment 11 Michiel de Bruijne 2006-10-08 02:20:25 UTC
(In reply to comment #7)
> As an example, take `emerge -u >=jdk-1.4`.  Should that that be greedy and pull
> in all slots for versions >=1.4, or should it pull in just the highest version
> of jdk?
> 

My vote goes to that it should be greedy and pull in all slots for versions >=1.4.

emerge -u =<cat>/<pack>/<slot|version> should pull in the highest version in that slot or the specified version.
Comment 12 Marius Mauch (RETIRED) gentoo-dev 2006-10-08 07:43:12 UTC
emerge targets should always be greedy for updates. You can always make it non-greedy by specifiying the SLOT you want (ok, not if you also specify a version restriction, but I think the use case of a user-given versioned atom matching multiple installed slots is extremely uncommon).
No need to bind it to any CLI option.
Comment 13 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-10-08 07:57:41 UTC
(In reply to comment #12)
> emerge targets should always be greedy for updates. You can always make it
> non-greedy by specifiying the SLOT you want (ok, not if you also specify a
> version restriction, but I think the use case of a user-given versioned atom
> matching multiple installed slots is extremely uncommon).
> No need to bind it to any CLI option.
> 

emerge -up >sys-kernel/gentoo-sources-2.6
Kernrel is slotted by ${PV} so this would match multiple SLOTS
(2.6.15, 2.6.16, and so on) and is quite a common case I would think.

However there is no need to do:

emerge -up >sys-kernel/gentoo-sources-2.6:2.6.17

Because I can just do:

emerge -up >sys-kernel/gentoo-sources:2.6.17

I'm not sure of any program that doesn't SLOT based on version..otherwise the two atoms kind of..intersect at times ;)
Comment 14 Marius Mauch (RETIRED) gentoo-dev 2006-10-08 08:29:15 UTC
Alec, kernels don't really matter here as you don't update them, every kernel version is a new install (they are slotted by $PVR) and my comment only was for updates (for new installs greedy behavior would be insane)
And as I said, generally if you specify a version restriction you don't match multiple slots, and for the rare case when you do there are always workarounds as long as we don't have support multiple slots per version.
Comment 15 Carsten Lohrke (RETIRED) gentoo-dev 2006-10-08 09:53:29 UTC
(In reply to comment #13)
> emerge -up >sys-kernel/gentoo-sources-2.6
> Kernrel is slotted by ${PV} so this would match multiple SLOTS
> (2.6.15, 2.6.16, and so on) and is quite a common case I would think.

All slotted ebuilds should be updated, if a previously installed ebuild version matching the slot is installed already - in contrast to an plain emerge, which should only install the latest slotted ebuild. This does imply, that the user has explicitly to emerge slotted kernel updates (as with any new slotted ebuild declared stable, that is not a dependency of another ebuild).

Comment 16 Andrei Slavoiu 2006-10-08 10:09:43 UTC
(In reply to comment #7)
> As an example, take `emerge -u >=jdk-1.4`. Should that that be greedy and
> pull in all slots for versions >=1.4, or should it pull in just the highest
> version of jdk?
Well, here's what I would expect (wish) as a Gentoo user that this command will do:
1. If both 1.4 and 1.5 slots are installed then they are both updated.
2. If only slot 1.5 is installed then it is updated.
3. If only slot 1.4 is installed then it is updated AND slot 1.5 is installed.
4. If no slot is installed then 1.5 is installed.
Of course, this assumes that only 1.4 and 1.5 slots are available and no p.masks are active :)
Comment 17 Zac Medico gentoo-dev 2006-10-08 14:49:07 UTC
I've fixed it in svn r4621 to make --update trigger greedy matches against installed slots. This patch allows a subset of installed slots to be pulled in via operators such as > or <.
Comment 18 Michiel de Bruijne 2006-10-08 15:34:31 UTC
Thanks Zac for your great work!
Comment 19 Zac Medico gentoo-dev 2006-10-08 18:59:43 UTC
This has been released in 2.1.2_pre2-r7.
Comment 20 Carsten Lohrke (RETIRED) gentoo-dev 2006-10-09 05:26:21 UTC
Doesn't seem to work. I do have Qt 3 and 4 installed, created a qt-3.9 and qt-4.5 ebuild for testing and Portage still does only update the latest slot.

# emerge qt -puv

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS   ] x11-libs/qt-4.5  0 kB [1]
Comment 21 Carsten Lohrke (RETIRED) gentoo-dev 2006-10-09 05:28:27 UTC
Uh, forget that - forgot to SET the slot var in my test ebuilds...
Comment 22 Max Lorenz 2006-10-20 14:53:29 UTC
Okay, I'm seeing something like Carlo only that I have only Qt 3 installed and there's an update for it (3.3.6-r4) but 'emerge -u' only pulls in Qt4.

# emerge -pu qt
[ebuild  NS   ] x11-libs/qt-4.1.4-r2  USE="...

# emerge -pu qt:3
[ebuild     U ] x11-libs/qt-3.3.6-r4 [3.3.6-r3]

# emerge -V
Portage 2.1.2_pre3-r5 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.3.6-r5, 2.6.17-gentoo-r8 i686)

Am I being stupid again or is there somthing hinky?
Comment 23 Zac Medico gentoo-dev 2006-10-20 15:19:27 UTC
(In reply to comment #22)
> # emerge -pu qt
> [ebuild  NS   ] x11-libs/qt-4.1.4-r2  USE="...

It's only greedy with respect to *installed* slots.  Otherwise, it might be too greedy and pull in a bunch of unwanted slots.
Comment 24 Zac Medico gentoo-dev 2006-10-20 15:23:47 UTC
(In reply to comment #22)
> # emerge -pu qt
> [ebuild  NS   ] x11-libs/qt-4.1.4-r2  USE="...
> 
> # emerge -pu qt:3
> [ebuild     U ] x11-libs/qt-3.3.6-r4 [3.3.6-r3]

Actually, it seems like it should have pulled in the qt:3 update with the first command.  Can you file a new bug with --debug output for the first command?
Comment 25 Max Lorenz 2006-10-20 16:22:30 UTC
(In reply to comment #24)
> Actually, it seems like it should have pulled in the qt:3 update with the first
> command.  Can you file a new bug with --debug output for the first command?

bug #152175