Somewhere back in 2017, something installed virtual/jpeg:62 As a result, any subsequent compilations of packages using: virtual/jpeg:= Require this specific version *for me*, even though its no longer in tree, meaning --depclean will never remove it, no matter how often I reinstall slim. virtual/jpeg:62 was removed from tree back in 2019. The simplest fix would be to state: virtual/jpeg:0= However, this seems like the tip of a wormcan. Subsequently, CCing soap due to them being the one who removed this virtual version, because there may be other cases in tree affected by this. Quick scan also reveals: app-editors/ted dev-tcltk/tkimg gnustep-base/gnustep-gui media-gfx/flam3 media-gfx/iscan media-video/motion net-mail/asmail sci-geosciences/mapserver sci-libs/libgeotiff Most importantly, There seems to be no QA report metric that exposes these either!
Am I reading correctly that all of those packages depend on virtual/jpeg without a specific SLOT (ie, := instead of :0= )? It seems likely that, given the := would be there in order to trigger a source rebuild/reinstall when jpeg changes, that x11-misc/slim should likely depend on :0= (as it will need the source) rather than just := , but there are cases when it doesn't matter to the package what full-slot exists and the package's rebuild should be triggered anyways, so it seems like there may still be a portage bug here...
(In reply to Ian Stakenvicius from comment #1) > Am I reading correctly that all of those packages depend on virtual/jpeg > without a specific SLOT (ie, := instead of :0= )? > > It seems likely that, given the := would be there in order to trigger a > source rebuild/reinstall when jpeg changes, that x11-misc/slim should likely > depend on :0= (as it will need the source) rather than just := , but there > are cases when it doesn't matter to the package what full-slot exists and > the package's rebuild should be triggered anyways, so it seems like there > may still be a portage bug here... portage's behaviour is sadly "correct", the issue is however that: - I now have both slots - The "right" response is if you have both slots, and somebody does ":=", that the bind is to the largest one. So ":=" *should* be a thing people can do. However, this bug is introduced by the *removal* of the *largest* slot. The only way for a *user* to remedy this problem is to forcibly remove the *largest* slot, and reinstall things, and only then can portage do the right thing. I don't think portage can be expected to handle this problem as-is, but this does seem to be a very annoying class of problem that potentially occurs elsewhere.
(In reply to Kent Fredric (IRC: kent\n) from comment #2) > > portage's behaviour is sadly "correct", the issue is however that: > > - I now have both slots > - The "right" response is if you have both slots, and somebody does ":=", > that the bind is to the largest one. > > So ":=" *should* be a thing people can do. > > However, this bug is introduced by the *removal* of the *largest* slot. > > The only way for a *user* to remedy this problem is to forcibly remove the > *largest* slot, and reinstall things, and only then can portage do the right > thing. > > I don't think portage can be expected to handle this problem as-is, but this > does seem to be a very annoying class of problem that potentially occurs > elsewhere. As SLOT values are arbitrary, there technically isn't any "largest" vs "smallest" slot. Slot-operator behaviour is supposed to trigger a rebuild on the basis of equality vs difference, and the removal of an atom satisfying a particular (sub)slot in VDB of another package is exactly what is supposed to trigger a rebuild. There's definitely an issue in portage here as the whole reason slot operators exist is to trigger rebuilds of rdeps when a new slot is installed or an old one (that is still relied upon) is removed. That doesn't change the issue in this case, though, where x11-misc/slim should either be depending on either virtual/jpeg:0= (the convention taken for subslotted-full-API-vs-binary-only-compatibility-libs), or virtual/jpeg:* (ie API-not-required-any-lib-on-disk-will-do).
I wonder if renaming virtual/jpeg/jpeg-0.ebuild to jpeg-100.ebuild would resolve this. Perhaps portage might trigger a rebuild when the "newer" version is installed.
(In reply to Mike Gilbert from comment #4) > I wonder if renaming virtual/jpeg/jpeg-0.ebuild to jpeg-100.ebuild would > resolve this. > > Perhaps portage might trigger a rebuild when the "newer" version is > installed. Yes, that will certainly work. Also a !!virtual/jpeg:62 blocker would be a simple way to force people to manually remove virtual/jpeg:62. In theory, a soft !virtual/jpeg:62 blocker could be used to trigger automatic unmerge of virtual/jpeg:62, and rebuild of x11-misc/slim. However, emerge is currently not capable of automating that scenario.
I ran a quick test: 1. Resurrected virtual/jpeg-62 in the gentoo repo. 2. Installed virtual/jpeg-0-r3 and virtual/jpeg-62. 3. Installed x11-misc/slim. 4. Removed virtual/jpeg-62 from the gentoo repo. 5. Renamed virtual/jpeg-0-r3 to virtual/jpeg-100 (SLOT=0). 6. Ran emerge -uDN @world The world update pulled in virtual/jpeg-100 and triggered a rebuild of x11-misc/slim. If there are no objections, I will rename virtual/jpeg-0-r3 to virtual/jpeg-100 tomorrow.
(In reply to Mike Gilbert from comment #6) > If there are no objections, I will rename virtual/jpeg-0-r3 to > virtual/jpeg-100 tomorrow. It looks ok to me, *6 days later* :P
(In reply to Kent Fredric (IRC: kent\n) from comment #7) > (In reply to Mike Gilbert from comment #6) > > If there are no objections, I will rename virtual/jpeg-0-r3 to > > virtual/jpeg-100 tomorrow. > > It looks ok to me, *6 days later* :P Yeah, do it. That'll just bring it into alignment with business as usual.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e77df397ccdd60bdb107db247c1a6f49328686fb commit e77df397ccdd60bdb107db247c1a6f49328686fb Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-06-05 03:35:21 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-06-05 03:35:21 +0000 virtual/jpeg: bump to version 100 Should cause a rebuild for any installed reverse dependencies that were built against the "62" slot. Bug: https://bugs.gentoo.org/725944 Signed-off-by: Mike Gilbert <floppym@gentoo.org> virtual/jpeg/{jpeg-0-r3.ebuild => jpeg-100.ebuild} | 0 1 file changed, 0 insertions(+), 0 deletions(-)
