| Summary: | [java-overlay] dev-java/icedtea-6.1.8.0: Change order of vm dependencies | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ralph Sennhauser (RETIRED) <sera> |
| Component: | [OLD] Java | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 247140 | ||
| Attachments: | mentioned patch | ||
|
Description
Ralph Sennhauser (RETIRED)
2010-04-17 19:28:47 UTC
Created attachment 228203 [details, diff]
mentioned patch
Have you tried boostrapping icedtea (installing it without a JDK already installed) with your patch applied? (In reply to comment #0) > The order when specifying a dependency of the form || ( ..) matters. Someone > installing icedtea:6 wants icedtea:6 on his system and the other choises of vms > are merely for building it in the first place. I'd say it's a bug in the package manager if it doesn't allow uninstall (or wants to install back) the first of the alternative when a different alternative is already available. AFAIK portage handles this just fine. Which exact package manager+version do you mean, or can you point me to any specification/docs that say the order matters so much? (In reply to comment #2) > Have you tried boostrapping icedtea (installing it without a JDK already > installed) with your patch applied? Exactly. If your package manager is so strict to require the first alternative to be available, it will probably fail at this point. If not, its behavior is even weirder (force you to always install the first alternative, yet gracefully skip to other alternatives if there're circular deps). I'd think current portage could handle this change, but I don't currently see the point. Zac: any comment pls? :) (In reply to comment #2) > Have you tried boostrapping icedtea (installing it without a JDK already > installed) with your patch applied? > If you mean without one of those listed as possible dependencies of icedtea, then yes I did. I installed version 6.1.7.3::java-overlay, explicitly uninstalled icetea6-bin::gentoo and updated to 6.1.8.0::java-overlay using 6.1.7.3::java-overlay. Both icedtea ebuilds were modified accordingly and icedtea6-bin wasn't pulled in during update of icedtea:6. However your concern seems to be the error massage which will(should) change to a circular dependency error message in case non of the other options is installable (keywords, masks, digests, whatever). This might well be less informative. However I expect an ~arch user to be able to overcome such a hurdle. If I got you wrong please tell me so I have a clue what to test for. Mind a single run takes more than an hour here. To be cleaned up by --depclean, --uninstall-unused or --clean the order in virtual/jdk:1.6 would need to be changed accordingly, however as icedtea is not in the main tree I guess this has to wait for now or I should simply use the virtual in the overlay. :) Cheers (In reply to comment #3) > (In reply to comment #0) > > The order when specifying a dependency of the form || ( ..) matters. Someone > > installing icedtea:6 wants icedtea:6 on his system and the other choises of vms > > are merely for building it in the first place. > > I'd say it's a bug in the package manager if it doesn't allow uninstall (or > wants to install back) the first of the alternative when a different > alternative is already available. AFAIK portage handles this just fine. Which > exact package manager+version do you mean, or can you point me to any > specification/docs that say the order matters so much? > > (In reply to comment #2) > > Have you tried boostrapping icedtea (installing it without a JDK already > > installed) with your patch applied? > > Exactly. If your package manager is so strict to require the first alternative > to be available, it will probably fail at this point. If not, its behavior is > even weirder (force you to always install the first alternative, yet gracefully > skip to other alternatives if there're circular deps). I'd think current > portage could handle this change, but I don't currently see the point. > > Zac: any comment pls? :) > I'm quite positive that a package manager should use the first which is installable when resolving dependencies. It will have to wait for a few hours for me to look up the specification on the exact details. Till then the comment 4 might shed some light on what I mean. I don't see a bug in any package manager but a hidden feature of || () dependencies. Oh, now I see where I created confusion. It only pulls in icetea6-bin as an update to an older version of icetea6-bin. And of course "I'm quite positive that a package manager should use the first which is installable when resolving dependencies" should be "I'm quite positive that a package manager should use the first which is installable if there isn't one installed already when resolving dependencies" Sorry for that. The order is still relevant. Cheers. (In reply to comment #6) > Oh, now I see where I created confusion. It only pulls in icetea6-bin as an > update to an older version of icetea6-bin. So if you uninstall icedtea6-bin manually and then try to update/reinstall icedtea, will it pull icedtea6-bin back or not? I don't see a problem with the current order if it just makes it update the deps (better than keeping old vulnerable versions around anyway). > And of course "I'm quite positive > that a package manager should use the first which is > installable when resolving dependencies" should be "I'm quite positive that a > package manager should use the first which is > installable if there isn't one installed already when resolving dependencies" I would agree with the corrected statement. If that would be true, the current order is fine. (In reply to comment #4) > However your concern seems to be the error massage which will(should) change to > a circular dependency error message in case non of the other options is > installable (keywords, masks, digests, whatever). This might well be less > informative. However I expect an ~arch user to be able to overcome such a > hurdle. I'd rather not put such hurdles on the users, but fix the package manager. > If I got you wrong please tell me so I have a clue what to test for. Mind a > single run takes more than an hour here. Simply uninstall icedtea6-bin and icedtea and try installing icedtea (with your order changes). If paludis has something similar to quickpkg, you could backup your current packages, uninstall them, see how the deps resolve (no need to build it to the end) and restore the backed up pacakges. > To be cleaned up by --depclean, --uninstall-unused or --clean the order in > virtual/jdk:1.6 would need to be changed accordingly, however as icedtea is not > in the main tree It is for some time :) >I guess this has to wait for now or I should simply use the > virtual in the overlay. :) Why? > Cheers > I noticed I had the wrong perception on the resolution.
To rephrase assuming I have non of the vms installed emerging icetea:6 pulls in ictea6-bin. Now --depclean should be allowed to remove icetea6-bin as it's not part of world and in practice not required anymore.
This is prevented by the orderer in the virtual/jdk:6 and the icedtea:6 ebuild alone, so I thought, however after looking into the pms again it looks like eapi 4 is required to achieve my goal in a sane way if I don't miss something.
As it is now if one not explicitly uninstalls icetea6-bin updating icedtea:6 will update icedtea6-bin (if a newer version is installable) and then use icedtea:6 to update icedtea:6. It's not that small a download.
Still for now it looks like the current order is the best choice.
> I don't see a problem with the current order if it just makes it update the
> deps (better than keeping old vulnerable versions around anyway).
I agree, but even better would be to let the package manager remove them if not needed in the first place.
|