| Summary: | portage-2.1.10.15 regression of masked item acceptance | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Derk W te Bokkel <derk.tebokkel> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=547332 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 381649 | ||
|
Description
Derk W te Bokkel
2011-09-11 02:33:03 UTC
#current package.mask
=virtual/jre-1.7
=virtual/jdk-1.7
dev-java/oracle-jdk-bin
dev-java/oracle-jre-bin
>=sys-block/parted-3.0
>=sys-block/gparted-0.9.0
# no issues with portage 2.1.10.14
=sys-apps/portage-2.1.10.15
It's due to this commit which is needed in order for the latest version to be pulled in: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=21330075f07248765016e104b3ba8216903f1ecb Generally, newer versions are a good thing, and this wouldn't be a problem if there was another virtual/jdk-1.7.0 provider with a license matched by the default ACCEPT_LICENSE settings. I'll have to ponder this to see if I can come up with some kind of compromise. note: I forgot to add that it also requests the unmask of oracle-jdk-bin as well. i.e make the changes to package.mask as well ... virtually the same lines .. .. even if the package.mask is set-up as above .. it is reaching around the all the masks to pull the newer versions in .. which defeats the purpose of the masking .. the emerge list includes virtual/jdk-1.7, virtual/jre-1.7 and dev-java/oracle-jdk-bin-1.7... note the other items in the mask list .. the newest version of gparted and parted together have reduced functionality I want the older added functionallity so I mask the newer versions .. if portage starts reaching past these masks why bother masking at all .. then I have to start using customized ebuilds in my personal tree .. not every-one will do this. we should be able to select via masking whether we want those packages or not.. when we mask intentionally and they still become available (messing up emerges) it can cause real issues. At the worst a warning that certain software needs these masks but will not be installed due to missing dependencies is okay .. a masks change request is okay as well.. but if I choose not to ..it should not stop the emerge ..locking out the entire emerge is a real pain .. especially for a large number of packages when not all are effected. Would a two pass model work .. if we turn down a request for mask changes .. request if we want the rest of the packages emerged .. and pop-out offending packages .. then re-run emerge with all emergeable packages .. Note: I usually use --ask (-a) in my emerge requests I've reverted the change in behavior: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a83f1864180ac88675bfd633617d835e9e42c1de I'll try for less different approach that will only pull in the update if the dependencies aren't masked. thank you .. let me know if i can test anything for you .. Derk I've got a new patch here that pulls in the virtual slot updates only if their dependencies are not masked: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b95cbb6b78ad6d9b8e2d3edc5fafff122c3ce7c5 It has tests that prove that it works, so it's not necessary for you to test it. This is fixed in 2.1.10.16 and 2.2.0_alpha56. |
