Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 383323 - sys-apps/portage: emerges pulls in older jdk slot when newer slot is masked (newer masked slot remains until depclean)
Summary: sys-apps/portage: emerges pulls in older jdk slot when newer slot is masked (...
Status: RESOLVED DUPLICATE of bug 250418
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-17 09:54 UTC by Klaus Kusche
Modified: 2020-03-03 21:49 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2011-09-17 09:54:06 UTC
Last saturday, my "emerge --deep --update --newuse system world"
showed nothing to emerge: Everything was up to date, all dependencies satisfied
(I'm on ~amd64).

Today, I synced, updated portage to 2.1.10.18, and again did 
"emerge -pv --deep --update --newuse system world".

For some strange reasons, it suddenly wanted to emerge NS virtual/jre-1.6,
NS virtual/jdk-1.6, and N dev-java/icedtea6-bin-1.10.3.

I'm absolutely sure that I have installed nothing requiring those packages:
I've virtual/jre-1.7, satisfied by virtual/jdk-1.7, satisfied by
dev-java/oracle-jdk-bin-1.7.0, and that satisfies all my dependencies on java.

"emerge --tree" showed that virtual/jdk-1.6 was pulled in (indirectly via
4 other packages) *by itself*!

So I removed the jdk-1.[56] and jre-1.[56] ebuilds from /usr/portage.

Now, "emerge -pv --deep --update --newuse system world" wanted to emerge
dev-java/oracle-jre-bin-1.7.0-r1 (in parallel to the already-installed
oracle-jdk-bin-1.7.0), "--tree" showed that this was pulled in by
virtual/jre-1.7.

To stop that, I edited the virtual/jre-1.7 ebuild:
#RDEPEND="|| (
#               =virtual/jdk-1.7.0*
#               =dev-java/oracle-jre-bin-1.7.0*
#       )"
RDEPEND="=virtual/jdk-1.7.0*"

That made "emerge -pv --deep --update --newuse system world" happy:
Neither did it try to emerge anything java-related, nor did it complain about
any missing dependencies (which also clearly indicates that nothing needs 
an 1.6 jdk or jre).

So why did it try to slot-install the 1.6 versions,
and why did it try to install the 1.7 jre in parallel to the 1.7 jdk?

Either something in the java ebuild DEPENDs is messed up,
or portage miscalculates dependencies.
Comment 1 Derk W te Bokkel 2011-09-17 18:16:21 UTC
problem occurs because virtual/jdk-1.7 and virtual/jre-1.7 are currently hard masked .. so portage acts as it is supposed to and pulls the "next slot in"  .. 
unmask the virtuals in your /etc/portage/package.unmask .. and the error should disappear else re-comment on this bug.
Comment 2 Klaus Kusche 2011-09-17 18:34:34 UTC
You are correct. Unmasking them keeps emerge from emerging the 1.6 versions.

However, some questions (w.r.t. portage) remain:

1.) Why didn't emerge complain that I have masked packages on my system
which are used by some dependencies?
(it definitely did some time ago, and that would have helped me to save 
some time and this bug report)

2.) I think it should not only have installed the 1.6 slot,
it should also have *unmerged* the masked 1.7 slot (which it did not!),
otherwise, installing the 1.6 slot makes no sense,
because 1.7 would have been used anyway...

3.) Especially after I deleted the 1.5 and 1.6 ebuilds from /usr/portage,
emerge should either have complained that I have unresolvable dependencies,
or it should have complained that dependencies are resolved to masked packages,
because there was no other alternative to satisfy the java dependencies! 
However, emerge remained silent as if anything was fine and happy...
Comment 3 Derk W te Bokkel 2011-09-17 18:39:27 UTC
Those questions I will leave for the developers to handle .. as it seems you have uncovered another regression  ..
Comment 4 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2011-09-18 20:53:28 UTC
CCing portage wrt questions from comment 2, please feel free to take over or close this bug. The jdk-1.7 and jre-1.7 are indeed masked and if someone wants oracle-jdk-bin-1.7 exclusively, unmask them locally.
Comment 5 Zac Medico gentoo-dev 2011-09-18 21:24:47 UTC
Since portage-2.1.10.15 and 2.2.0_alpha56, we've had various issues related to bug 382557. Please post emerge --version output.

There's a fix in git that solves an issue with --depclean removing jdk-1.7 immediately after it's been installed:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c7474fe52e1c52bb6b17bc56ae489d8efc3c0ef3
Comment 6 Zac Medico gentoo-dev 2011-09-18 21:36:49 UTC
(In reply to comment #2)
> 1.) Why didn't emerge complain that I have masked packages on my system
> which are used by some dependencies?
> (it definitely did some time ago, and that would have helped me to save 
> some time and this bug report)

Was it really masked, or did you just delete the ebuild? Deleting the ebuild is not enough to trigger warnings, since we want emerge to be able to gracefully work from binary packages alone.

> 2.) I think it should not only have installed the 1.6 slot,
> it should also have *unmerged* the masked 1.7 slot (which it did not!),
> otherwise, installing the 1.6 slot makes no sense,
> because 1.7 would have been used anyway...

That sounds similar to bug 350285 (again, you need to tell us your portage version in order to know if it has a fix for a given bug).

> 3.) Especially after I deleted the 1.5 and 1.6 ebuilds from /usr/portage,
> emerge should either have complained that I have unresolvable dependencies,
> or it should have complained that dependencies are resolved to masked packages,
> because there was no other alternative to satisfy the java dependencies! 
> However, emerge remained silent as if anything was fine and happy...

Again, that's part of the design, which allows emerge to function happily with binary packages alone.
Comment 7 Zac Medico gentoo-dev 2011-09-18 21:42:45 UTC
Oh, I just notice the portage version 2.1.10.18 in the summary.

(In reply to comment #0)
> Now, "emerge -pv --deep --update --newuse system world" wanted to emerge
> dev-java/oracle-jre-bin-1.7.0-r1 (in parallel to the already-installed
> oracle-jdk-bin-1.7.0), "--tree" showed that this was pulled in by
> virtual/jre-1.7.

This kind of behavior typically indicates some kind of problem with the installed package. Please create a tarball of /var/db/pkg/dev-java/oracle-jdk-bin-1.7, in case we need if for later analysis, and re-install that package to see if it makes any difference.
Comment 8 Zac Medico gentoo-dev 2011-09-18 22:04:04 UTC
(In reply to comment #6)
> (In reply to comment #2)
> > 2.) I think it should not only have installed the 1.6 slot,
> > it should also have *unmerged* the masked 1.7 slot (which it did not!),
> > otherwise, installing the 1.6 slot makes no sense,
> > because 1.7 would have been used anyway...
> 
> That sounds similar to bug 350285

This commit should fix a similar issue:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c7474fe52e1c52bb6b17bc56ae489d8efc3c0ef3
Comment 9 Zac Medico gentoo-dev 2011-09-18 22:13:22 UTC
(In reply to comment #8)
> > That sounds similar to bug 350285
> 
> This commit should fix a similar issue:
> 
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c7474fe52e1c52bb6b17bc56ae489d8efc3c0ef3

Actually, no. A similar issue should be fixed by the fix from bug 382557, but portage-2.1.10.18 already has that fix.
Comment 10 Zac Medico gentoo-dev 2011-09-18 22:14:58 UTC
(In reply to comment #7)
> (In reply to comment #0)
> > Now, "emerge -pv --deep --update --newuse system world" wanted to emerge
> > dev-java/oracle-jre-bin-1.7.0-r1 (in parallel to the already-installed
> > oracle-jdk-bin-1.7.0), "--tree" showed that this was pulled in by
> > virtual/jre-1.7.
> 
> This kind of behavior typically indicates some kind of problem with the
> installed package. Please create a tarball of
> /var/db/pkg/dev-java/oracle-jdk-bin-1.7, in case we need if for later analysis,
> and re-install that package to see if it makes any difference.

Please go ahead and try to re-install oracle-jdk-bin-1.7, after making a backup tarball of the /var/db/pkg/dev-java/oracle-jdk-bin-1.7 directory.
Comment 11 Klaus Kusche 2011-09-19 05:37:28 UTC
(In reply to comment #6)
> (In reply to comment #2)
> > 1.) Why didn't emerge complain that I have masked packages on my system
> > which are used by some dependencies?
> > (it definitely did some time ago, and that would have helped me to save 
> > some time and this bug report)
> 
> Was it really masked, or did you just delete the ebuild? Deleting the ebuild is
> not enough to trigger warnings, since we want emerge to be able to gracefully
> work from binary packages alone.

The jre 1.7 and jdk 1.7 ebuilds (the versions I had installed on my system) 
were present and masked by
/usr/portage/profiles/package.mask >=virtual/jre-1.7.0 >=virtual/jdk-1.7.0

I *do* get a "masked" error if I try to emerge them explixitely,
but I didn't get any notice when running
"emerge --deep --update --newuse system world":
emerge just wanted to install the (not masked) 1.6 versions,
but did not touch the (masked) 1.7 versions or give any message about them.

> > 2.) I think it should not only have installed the 1.6 slot,
> > it should also have *unmerged* the masked 1.7 slot (which it did not!),
> > otherwise, installing the 1.6 slot makes no sense,
> > because 1.7 would have been used anyway...
> 
> That sounds similar to bug 350285 (again, you need to tell us your portage
> version in order to know if it has a fix for a given bug).

Portage is 2.1.10.18, as stated in the bug headline and original description.

It's not related to 350285, because 350285 is about depclean,
and I didn't try to depclean.

I just expected the same behaviour and end result as for nonslotted packages:
If you have version x installed, and version x gets masked afterwards, emerge
does an UD install, which installs version x-1 ***and removes version x***
(without depclean), forcing the correct version x-1 to be used.

For slotted packages, it NS-installs version x-1, but ***does not remove***
version x. It does not even tell you that something's wrong with version x.
In case of java, this means that the masked version x continues to be
the active version.

If version x were masked due to a security bug,
this behaviour is a serious problem!

> > 3.) Especially after I deleted the 1.5 and 1.6 ebuilds from /usr/portage,
> > emerge should either have complained that I have unresolvable dependencies,
> > or it should have complained that dependencies are resolved to masked packages,
> > because there was no other alternative to satisfy the java dependencies! 
> > However, emerge remained silent as if anything was fine and happy...
> 
> Again, that's part of the design, which allows emerge to function happily with
> binary packages alone.

I think you misunderstand.
It's not about portage not complaining about installed versions
for which no ebuild exists.
It's about portage not complaining about installed versions
for which all ebuilds are masked:
* I removed the ebuilds for slots 1.5 and 1.6.
* The ebuilds for slot 1.7 ***were still present*** 
(the only versions of the ebuilds still being there), 
but slot 1.7 was masked in /usr/portage/profiles/package.mask.
* I had the 1.7 versions installed.

Hence, all my java dependencies were satisfied by the (already installed,
but masked) 1.7 versions.

emerge should have complained that
* the java dependencies are currently satisfied by masked packages
and/or
* no unmasked packages were available to satisfy my java dependencies.

It did neither.
Comment 12 Klaus Kusche 2011-09-19 05:52:06 UTC
(In reply to comment #10)
> (In reply to comment #7)
> > (In reply to comment #0)
> > > Now, "emerge -pv --deep --update --newuse system world" wanted to emerge
> > > dev-java/oracle-jre-bin-1.7.0-r1 (in parallel to the already-installed
> > > oracle-jdk-bin-1.7.0), "--tree" showed that this was pulled in by
> > > virtual/jre-1.7.
> > 
> > This kind of behavior typically indicates some kind of problem with the
> > installed package. Please create a tarball of
> > /var/db/pkg/dev-java/oracle-jdk-bin-1.7, in case we need if for later analysis,
> > and re-install that package to see if it makes any difference.
> 
> Please go ahead and try to re-install oracle-jdk-bin-1.7, after making a backup
> tarball of the /var/db/pkg/dev-java/oracle-jdk-bin-1.7 directory.

The problem is completely unrelated to oracle-jdk-bin-1.7.

oracle-jdk-bin-1.7 works fine and is installed to satisfy 
the depends of jdk-1.7: 
All packages needing java depend on jre or jdk
==> jre depends on jdk
==> jdk depends on oracle-jdk-bin

Also, there are no masking or slot issues with oracle-jdk-bin (it is unmasked).

The problem only lies in the way portage behaves 
for the slotted jre and jdk virtuals (which also have correct ebuilds):
* Originally, the jre and jdk 1.7 versions were unmasked,
and I installed them (as the only slot on my system).
* They got masked after I had them installed,
but emerge did not react in the way I expected:
It did not tell me in any way about the mask, 
and it tried to additionally install the 1.6 versions
without removing the 1.7 versions (see previous comment).
Comment 13 Zac Medico gentoo-dev 2011-09-19 05:56:20 UTC
If jdk-1.7 is masked, the way that it's supposed to work is that you run an update command and it pulls in jdk-1.5 or jdk-1.6 as appropriate, without any warning message. Then, you're supposed to run emerge --depclean, which is supposed to remove the masked jdk-1.7.

(In reply to comment #11)
> It's about portage not complaining about installed versions
> for which all ebuilds are masked:
> * I removed the ebuilds for slots 1.5 and 1.6.
> * The ebuilds for slot 1.7 ***were still present*** 
> (the only versions of the ebuilds still being there), 
> but slot 1.7 was masked in /usr/portage/profiles/package.mask.
> * I had the 1.7 versions installed.
> 
> Hence, all my java dependencies were satisfied by the (already installed,
> but masked) 1.7 versions.
> 
> emerge should have complained that
> * the java dependencies are currently satisfied by masked packages

Yes, we have code that's supposed to trigger warning that says "The following installed packages are masked..." I'll see if I can reproduce what you are describing.
Comment 14 Klaus Kusche 2011-09-19 06:23:17 UTC
(In reply to comment #13)
> If jdk-1.7 is masked, the way that it's supposed to work is that you run an
> update command and it pulls in jdk-1.5 or jdk-1.6 as appropriate, without any
> warning message. Then, you're supposed to run emerge --depclean, which is
> supposed to remove the masked jdk-1.7.

Hmmm, not happy with that from the user's point of view,
because it differs from the way a mask-after-install
works for unslotted packages.

1.) For unslotted packages, I see an UD install, which clearly tells me
that my currently installed version has been masked or removed.

For slotted packages, I see an NS install, which doesn't give my any idea
***why*** portage wants to install that, and doesn't tell my that something
is wrong with my currently installed slot.

In fact, when I first saw the 1.6 slot install, I assumed that some package's
java depends were changed to require 1.6 explicitely, and checked all my
installed packages requiring java for that. I didn't realize the reason
was a mask on 1.7 until told by comment #2.

2.) As noted in my comment #11, it is unsafe.

If a version is masked for an unslotted package
(let's assume for security reasons, or for system-wide breakage),
the masked version will be replaced and removed by emerge,
and your system is safe and sane after the emerge, 
without the need to depclean.

For slotted packages, the masked version is still present and used
after the emerge, you don't even notice that it is dangerous.

I would not even depclean it, because I have no indication
that it is broken, and in general, I want the latest versions.
Comment 15 Zac Medico gentoo-dev 2020-03-03 21:49:03 UTC
(In reply to Klaus Kusche from comment #14)
> For slotted packages, the masked version is still present and used
> after the emerge, you don't even notice that it is dangerous.
> 
> I would not even depclean it, because I have no indication
> that it is broken, and in general, I want the latest versions.

In order to keep it, you would have to add it to your world file, and then you would get a notification that it's masked the next time that you try to update @world.

I think we can consider remaining issues as cases of bug 250418 or bug 372005.

*** This bug has been marked as a duplicate of bug 250418 ***