| 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
Thanks for filling this one for me :) 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). (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. 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. 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 (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. 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? (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? (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. (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. (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. 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. (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 ;) 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. (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). (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 :) 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 <. Thanks Zac for your great work! This has been released in 2.1.2_pre2-r7. 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] Uh, forget that - forgot to SET the slot var in my test ebuilds... 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? (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. (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? (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 |
