Created attachment 397568 [details] paludis-output.txt dev-lang/perl-5.20.1-r4 - stable, installed virtual/perl-Digest-SHA-5.820.0 - stable, installed virtual/perl-Digest-SHA-5.880.0 - stable perl-core/Digest-SHA-5.820.0 - stable perl-core/Digest-SHA-5.880.0 - unstable (none of these are in a set, nothing depends directly on perl-core/Digest-SHA except the virtual) So when I want to update my system, it pulls in virtual/perl-Digest-SHA-5.880.0 which has the dep-string > || ( =dev-lang/perl-5.20* ~perl-core/${PN#perl-}-${PV} ) Instead of choosing =dev-lang/perl-5.20* it tries to update to perl-core/Digest-SHA-5.880.0 which is in unstable arch and would need unmasking.
Note: perl team failed to bump virtuals when updating deps a few times. I fixed that for 5.20.2 upgrade but earlier versions may suffer similar issues.
It seems that mis-syncing virtuals with their perl-core versions confuses package managers. The questions are: * is it PMS compatible? (I think so) * does portage handle this similarly? * can this be reasonably fixed on PM side? * can the perl team make a policy that these mis-sycned ebuilds don't occur in the first place?
(In reply to Julian Ospald (hasufell) from comment #0) > > perl-core/Digest-SHA-5.820.0 - stable forgot to mention that this is installed as well
(In reply to Julian Ospald (hasufell) from comment #3) > (In reply to Julian Ospald (hasufell) from comment #0) > > > > perl-core/Digest-SHA-5.820.0 - stable > > forgot to mention that this is installed as well That's a problem. perl-core/* stuff that is going to handled by the dev-lang/perl package to be installed should actually be removed at some point. There are !atom deps that help with this but they're not foolproof. Further, if any perl-core/* packages are in @world, then you're guaranteed to have breakage. I don't think that is the case here though, correct?
(In reply to Ian Stakenvicius from comment #4) > (In reply to Julian Ospald (hasufell) from comment #3) > > (In reply to Julian Ospald (hasufell) from comment #0) > > > > > > perl-core/Digest-SHA-5.820.0 - stable > > > > forgot to mention that this is installed as well > > That's a problem. perl-core/* stuff that is going to handled by the > dev-lang/perl package to be installed should actually be removed at some > point. There are !atom deps that help with this but they're not foolproof. > Well, I am not sure the depstring is to blame here. We have similar problems with haskell depstrings that sometimes are very complex || ( ) constructs. Somehow paludis seems to have trouble with that. But then again, I don't really know much about the algorithms to say something useful here. But it at least seems to be PMS-compatible, although I'm not saying that PMS is non-broken ;) > Further, if any perl-core/* packages are in @world, then you're guaranteed > to have breakage. I don't think that is the case here though, correct? Correct. A similar thing occurs when we have another kind of mis-sync between virtual/perl-foo and perl-core/foo, as in: virtual/perl-Digest-SHA-5.880.0 - exists perl-core/Digest-SHA-5.880.0 - does not exist This has also happened in the past. I had to manually unmerge 20+ perl-core/ packages.
(In reply to Julian Ospald (hasufell) from comment #5) > > Further, if any perl-core/* packages are in @world, then you're guaranteed > > to have breakage. I don't think that is the case here though, correct? > > Correct. > > A similar thing occurs when we have another kind of mis-sync between > virtual/perl-foo and perl-core/foo, as in: > > virtual/perl-Digest-SHA-5.880.0 - exists > perl-core/Digest-SHA-5.880.0 - does not exist Incorrect.
(In reply to Andreas K. Hüttel from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5) > > > > Further, if any perl-core/* packages are in @world, then you're guaranteed > > > to have breakage. I don't think that is the case here though, correct? > > > > Correct. > > > > A similar thing occurs when we have another kind of mis-sync between > > virtual/perl-foo and perl-core/foo, as in: > > > > virtual/perl-Digest-SHA-5.880.0 - exists > > perl-core/Digest-SHA-5.880.0 - does not exist > > Incorrect. ++ We don't add perl-core package itself if core package just works fine in bundled perl distribution. Perl team don't see the point to do double work. When bundled module doesn't work it is another issue. I don't know how paludis handle these virtuals at all. It should not be a problem at all.
(In reply to Julian Ospald (hasufell) from comment #5) > > A similar thing occurs when we have another kind of mis-sync between > virtual/perl-foo and perl-core/foo, as in: > > virtual/perl-Digest-SHA-5.880.0 - exists > perl-core/Digest-SHA-5.880.0 - does not exist > > This has also happened in the past. I had to manually unmerge 20+ perl-core/ > packages. In that situation, then the virtual should: - Require the perl version in the || ( ) condition. - Request removal of all versions of perl-core/<namehere> Portage does so gracefully by default. ( Assuming no evil packages/world depend on the perl-core/<namehere> ) Paludis tends to need a bit of a helping hand and significant use of --permit-uninstalls ( And a few other truly crazy things I've managed to (fortunately for me, unfortunately for everyone else) forget. ) However, this does very much appear to be a rephrasing of bug #421495, the visibility of which has only slightly been reduced due to greatly narrowing the number of Perl versions we have as options. *** This bug has been marked as a duplicate of bug 421495 ***
(In reply to Kent Fredric from comment #8) > > *** This bug has been marked as a duplicate of bug 421495 *** No, this is not a duplicate. In the other bug a perl team member asked for a specific bug report. Here you have one. In addition, the perl team is in CC and not the assignee.
(In reply to Andreas K. Hüttel from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5) > > > > Further, if any perl-core/* packages are in @world, then you're guaranteed > > > to have breakage. I don't think that is the case here though, correct? > > > > Correct. > > > > A similar thing occurs when we have another kind of mis-sync between > > virtual/perl-foo and perl-core/foo, as in: > > > > virtual/perl-Digest-SHA-5.880.0 - exists > > perl-core/Digest-SHA-5.880.0 - does not exist > > Incorrect. Do you have anything useful to say for the actual bug report? The thing you commented on was just a sidenote.
It appears to me that this is a problem on paludis end. It has similar trouble with haskell depstrings where it picks the atom which causes the most intrusive configuration change (or even blockers) while there is an atom that doesn't require any configuration changes.
Paludis has been removed from the tee.
