On April 6 there was a change to portage that insists on upgrading perl from 5.22.3_rc4 to 5.24.1-r1, regardless of any keywording I can set myself. I found that the content of this particular ebuild had changed on that specific date as I had synced a similar system just a day before. The enforced upgrade is annoying and also does not upgrade any of the other perl packages, except some virtuals. I don't know if this was supposed to be some test case, but I'd appreciate it very much if you would undo it. See forum topic https://forums.gentoo.org/viewtopic-t-1061900.html for details.
This looks like a problem with configuration sadly, Perl 5.24 *is* stable on arm now, so in order to avoid it, you will need substantial masking of virtuals. Keywords for dev-lang/perl: | | u | | a a p s a n r | n | | l m h i p p r m m i i s | e u s | r | p d a p a p c a x m i 6 o s 3 | a s l | e | h 6 r p 6 p 6 r 8 6 p 8 s c 9 s | p e o | p | a 4 m a 4 c 4 c 6 4 s k 2 v 0 h | i d t | o --------------+---------------------------------+------------+------- 5.22.3_rc4 | + + + + + + + + + + ~ + o o + + | 5 o 0/5.22 | gentoo 5.22.3 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 5 o | gentoo --------------+---------------------------------+------------+------- 5.24.1_rc4 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 # 0/5.24 | gentoo 5.24.1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 # | gentoo 5.24.1-r1 | ~ ~ + ~ ~ + + ~ ~ + ~ ~ o o ~ ~ | 6 o | gentoo --------------+---------------------------------+------------+------- 5.26.9999 | o o o o o o o o o o o o o o o o | 6 o 0/5.25 | gentoo commit 89a762d3b518a35702c646b616abe8e7b913604b Author: Michael Weber <xmw@gentoo.org> Date: 2017-04-06 09:15:11 +1200 dev-lang/perl: arm arm64 ppc ppc64 stable (bug #604602) Package-Manager: Portage-2.3.5, Repoman-2.3.2 RepoMan-Options: --include-arches="amd64 arm arm64 ppc ppc64" dev-lang/perl/perl-5.24.1-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Please reopen if this does not satisfactorily explain your problem.
Sadly this does resolve the problem. I have keywords: dev-lang/perl -* =dev-lang/perl-5.22.3_rc4 * ~* ** Portage tells me to add ** to perl 5.24 rather then obey the provided keywords. It's somewhat ridiculous that I need to mask a number of virtuals with unpredictable version numbers (and in fact I have virtuals installed that appear to be happy with both 5.22 and 5.24) and portage refusing to install any packages because of this conflict. In essence: why didn't it tell me to add ~arm or ** on April 5th? Why does portage want to override the keywords I provide it since April 6th?
> Portage tells me to add ** to perl 5.24 rather then obey the provided keywords. This is more a problem in portage than in Perl's packaging. Portage opts to upgrade everything it can, and is not very bright about resolving problems when the graph is inconsistently keyworded. In short, masking dev-lang/perl is *not* enough, *because* you have about *30* virtuals that are unmasked which require a newer Perl. Portage can't solve that. You have to mask *each* and *every* offending virtual on top of perl itself.
> (and in fact I have virtuals installed that appear to be happy with both 5.22 and 5.24) Yes, this is because virtuals map to internal perl facets. Some of those facets have not changed between upstream perl releases, while others have. This is essentially *why* we have virtuals in the first place. It sucks really, but its the best we can do. Nobody has found a better solution :/ However, if you want a quick-start on what looks like to be a rough approximation of what you need to mask, ... grep '5.24' virtual/perl-*/*.ebuild | grep -v '5.22' | cut -f 1 -d ":" | sed 's|/perl-[^/]*/|/|;s|.ebuild$||;s|^|=|'
Ah, I see. I think I did mention this to be a portage problem? The thing here is: why does portage obey the ~arm in the ebuild, but not obey the keyword settings provided by the user? Worse even: at one point I deleted the 5.24 ebuilds from the tree and recreated the manifest, but it still wanted to install 5.24, complaining that there was no ebuild for it. And of course: the world update does not appear to want to rebuild any of the actual perl components even though I did specify --deep and I think portage should complain about a lot more things in this case, but it doesn't. So if this issue was assigned to the wrong team, how do I get it assigned to the right team?
Like this ;)
If I had the time I could sit down and make some mask files for "keep 5.22" and "keep 5.24" like I have built for 5.26-in-progress: https://github.com/gentoo-perl/perl-testing-profiles/blob/master/5.26.9999/profile/package.mask/perl https://github.com/gentoo-perl/perl-testing-profiles/blob/master/5.26.9999/profile/package.provided/perl These would mitigate partially the limitations portage currently has with uncomputable exponential resolving of problems. I just don't atm because I've been bogged down with this death march: https://bugs.gentoo.org/showdependencytree.cgi?id=613764&hide_resolved=0 Which is ultimately the reason 5.24 is getting stabilized _now_ Because 5.26 is going to be a *nightmare* and 5.24 needs to be out of the way or we're going to have some real problems.
Since you're going to have to use package.mask for a lot of packages in order to avoid the perl-5.24 update, the --autounmask-keep-masks option maybe be useful in order to prevent emerge from trying to undo package.mask settings as a means to satisfy dependencies.
While that doesn't prompt changing the masks, it still appears to block all updates +++++ emerge -1pvuND --verbose-conflicts --autounmask-keep-masks @world !!! All ebuilds that could satisfy "=dev-lang/perl-5.24*" have been masked. !!! One of the following masked packages is required to complete your request: - dev-lang/perl-5.24.1-r1::gentoo (masked by: package.mask, missing keyword) - dev-lang/perl-5.24.1::gentoo (masked by: package.mask, missing keyword) - dev-lang/perl-5.24.1_rc4::gentoo (masked by: package.mask, missing keyword) (dependency required by "virtual/perl-Scalar-List-Utils-1.420.200_rc-r1::gentoo" [ebuild]) (dependency required by "dev-perl/Sub-Install-0.928.0::gentoo" [installed]) (dependency required by "dev-perl/Data-OptList-0.110.0::gentoo" [installed]) (dependency required by "dev-perl/Sub-Exporter-0.987.0::gentoo" [installed]) (dependency required by "dev-perl/Getopt-Long-Descriptive-0.97.0::gentoo" [installed]) (dependency required by "app-admin/bubba-frontend-2.6-r2::bubba" [installed]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. +++++
(In reply to Gordon Bos from comment #9) > emerge -1pvuND --verbose-conflicts --autounmask-keep-masks @world > > !!! All ebuilds that could satisfy "=dev-lang/perl-5.24*" have been masked. > !!! One of the following masked packages is required to complete your > request: > - dev-lang/perl-5.24.1-r1::gentoo (masked by: package.mask, missing keyword) > - dev-lang/perl-5.24.1::gentoo (masked by: package.mask, missing keyword) > - dev-lang/perl-5.24.1_rc4::gentoo (masked by: package.mask, missing keyword) > > (dependency required by > "virtual/perl-Scalar-List-Utils-1.420.200_rc-r1::gentoo" [ebuild]) You need to add this version of virtual/perl-Scalar-List-Utils to package.mask.
Obviously, this is not a workable "solution". You cannot expect users to go figure out themselves which updates want to pull in an unwanted and/or conflicting update of something else. Since there is no obvious relation between the versions of the (virtual) packages and the perl version they are linked to, how about doing this the same as with python and ruby? i.e. add a PERL_TARGETS keyword, perl_targets_perl[version] USE flag.
(In reply to Gordon Bos from comment #11) > Since there is no obvious relation between the versions of the (virtual) > packages and the perl version they are linked to, how about doing this the > same as with python and ruby? i.e. add a PERL_TARGETS keyword, > perl_targets_perl[version] USE flag. That doesn't make the problem better, it just changes the kind of problem you have. Then you'll have lots of unsolvable conflicts because the USE flags are exposed differently. PERL_TARGETS comes up frequently as a solution, one we frequently reconsider, but the answers are always the same, it doesn't make the problem better, and just creates more in different places. Portage can be very tricky to reason about sometimes, and arbitrary changes *hoping* they'll be better often end up being worse.
I don't think you fully grasp the problem at hand. The forced upgrade *is* already causing 'lots of unsolvable conflicts'. It's the same on the forum. You're all very helpful in making the upgrade pass, but you're not willing to accept that there may be pressing reasons for staying on the older version. When it comes to keeping perl at this older version you expect users to go into some trial and error loop bumping their heads to the same stone over and over again. Endlessly, because every day a new package can be released that needs to be massked. Until the user has a 1TB package.mask file and portage crashes on the size of it. And of course when the reason for staying on older perl is lifted the user will have to figure out which of the one million packages named in there was related to holding back perl and will now cause a conflict when they do want to upgrade. I fail to see why it is to be so damn hard to keep perl at a certain version and one needs to mask numerous seemingly unrelated packages to keep portage from trying to resolve a conflict by creating one.
(In reply to Gordon Bos from comment #13) > I don't think you fully grasp the problem at hand. > > The forced upgrade *is* already causing 'lots of unsolvable conflicts'. It's > the same on the forum. You're all very helpful in making the upgrade pass, > but you're not willing to accept that there may be pressing reasons for > staying on the older version. On the contrary, I understand the problem, sufficient I have ideas that I want to make it possible to install and test Perl 5.6 using emerge, but in *userspace*, instead of OS tooling. I know this isn't great at present, but trying to make this work requires fighting with portage's mentality. And as much as I accept the situation is horrible, it works as-is for a lot of people without much hands-involved. The problem is your proposed solution means we can no longer convince portage to solve the problem for us, and instead, will fold back into a "Portage gets confused every time" problem, where the best it will do is convince you to change your configuration to appease it. > When it comes to keeping perl at this older > version you expect users to go into some trial and error loop bumping their > heads to the same stone over and over again. Endlessly, because every day a > new package can be released that needs to be massked. Until the user has a > 1TB package.mask file and portage crashes on the size of it. > And of course > when the reason for staying on older perl is lifted the user will have to > figure out which of the one million packages named in there was related to > holding back perl and will now cause a conflict when they do want to upgrade. This problem will still happen with communicating the issue to USE flags, just instead of some confusing subslot conflict, you'll have some confusing USE error ( which will require manual resolution to resolve in hardcoded configs, as opposed to just increasing backtrack ) > > I fail to see why it is to be so damn hard to keep perl at a certain version > and one needs to mask numerous seemingly unrelated packages to keep portage > from trying to resolve a conflict by creating one. Again, this is a problem in Portage implementation, where portage has no sane way of disambiguating between "user wants" and "user configured it that way because portage wanted them to", and no way to disambiguate between "user wants" and "gentoo maintainers made possible", portage treats them all as a contiguous blob. I assure you, I feel your pain, and I get crippling anxiety every time I see this problem and I lose sleep trying to think of a solution, but they all turn out to be worse than the status quo. To do anything remotely like what you propose, we'd need to sit down and invest substantially in making the right glue appear, and then relatively substantial testing of the proposal in isolation, and only then would it be something we could consider migrating to the main tree once it proved itself. But we simply don't have the staff to pull off something so heroic, especially something which has dubious utility and may make things *worse* But as it is, Portage lives in the reality of "if there is any kind of upgrade, we should make it happen", and you'll have to counter-act that fundamental design in order to "stay old" Perl team trying to fight this on your behalf can only work so well, so instead, we're pushing for portage to do what you want to do instead, because at least that can actually work.
Okay, I get your point. The annoying thing here however is that I still appear to be addressing the Perl team for an issue that was reported about incorrect portage behaviour. And it is in fact not only perl where portage pushes new versions while it shouldn't. e.g. I have in my world file sys-kernel/gentoo-sources:4.4.39 but when I run world updates it wants to install 4.10 kernel sources. I'm quite certain that previous versions of portage did not do that, so something got broken somewhere.
Closing as none of the related packages are in the current portage tree any more.
