Tracker for perl 5.18 related bugs. Reproducible: Always
Depends on https://bugs.gentoo.org/show_bug.cgi?id=506374
Nothing left to do here, so preparing the stabilization request.
Created attachment 381406 [details] list of packages to be stabilized, v1 First, untested version of the stabilization list attached. See the list for instructions.
Created attachment 381424 [details] list of packages to be stabilized, v2 Add needed perl-core package
Dear arches, it's Perl stabilization time again! Perl 5.18 this time. Target: all stable arches Please locally keyword ALL ebuilds in the attached list, then upgrade ALL present and test, and if everything is fine, stabilize ALL of them together. If problems occur, please DO NOT stabilize only part of the list. Some of the virtual ebuilds may already be stable on your arch now. This is no cause for concern.
Bug 517906 is a serious blocker since it gets people stuck in the middle of the upgrade. Not that this was ever easy with perl... :( Will CC arches back once this detail is solved. If you are already stuck during arch testing, ping me on IRC. I *think* I know the solution.
(In reply to Andreas K. Hüttel from comment #6) > Bug 517906 is a serious blocker since it gets people stuck in the middle of > the upgrade. Not that this was ever easy with perl... :( > > Will CC arches back once this detail is solved. > > If you are already stuck during arch testing, ping me on IRC. I *think* I > know the solution. I went trhough with this and the two dependent stabilizations for Alpha. So what's the magic I'm supposed to do? Going back is going to be quite a PITA.
(In reply to Tobias Klausmann from comment #7) > I went trhough with this and the two dependent stabilizations for Alpha. > > So what's the magic I'm supposed to do? Going back is going to be quite a > PITA. Don't go back (it breaks things even worse). Just do nothing, as we discussed on irc.
And we're back. Arches please do, see blocker bugs and attached list for the packages to be stabilized. [If you run into blockers in the subsequent perl-cleaner run, new app-admin/perl-cleaner-2.16 now fails with detailed instructions how to fix. I bumped that straight to stable since the only changes are output messages.]
I stabilized perl-tk (dependent bug) just now and Alpha is done.
amd64 stable
I don't know where the responsibility lays. Frankly I don't care. I am seeing way too many "blocks" and other emerge stoppages on many machines. This was pulled from a minimal recent install. [blocks B ] <perl-core/ExtUtils-MakeMaker-6.660.0 ("<perl-core/ExtUtils-MakeMaker-6.660.0" is blocking virtual/perl-ExtUtils-MakeMaker-6.660.0-r1) [blocks B ] <perl-core/Module-CoreList-3.30.0 ("<perl-core/Module-CoreList-3.30.0" is blocking virtual/perl-Module-CoreList-3.30.0) [blocks B ] <perl-core/ExtUtils-Install-1.590.0 ("<perl-core/ExtUtils-Install-1.590.0" is blocking virtual/perl-ExtUtils-Install-1.590.0-r1) [blocks B ] <perl-core/version-0.990.200 ("<perl-core/version-0.990.200" is blocking virtual/perl-version-0.990.200-r1) [blocks B ] <perl-core/ExtUtils-CBuilder-0.280.210 ("<perl-core/ExtUtils-CBuilder-0.280.210" is blocking virtual/perl-ExtUtils-CBuilder-0.280.210-r1) [blocks B ] <perl-core/ExtUtils-Manifest-1.630.0 ("<perl-core/ExtUtils-Manifest-1.630.0" is blocking virtual/perl-ExtUtils-Manifest-1.630.0-r1) [blocks B ] <perl-core/IO-1.280.0 ("<perl-core/IO-1.280.0" is blocking virtual/perl-IO-1.280.0-r1) [blocks B ] <perl-core/IPC-Cmd-0.800.0 ("<perl-core/IPC-Cmd-0.800.0" is blocking virtual/perl-IPC-Cmd-0.800.0-r1) [blocks B ] <perl-core/Storable-2.410.0 ("<perl-core/Storable-2.410.0" is blocking virtual/perl-Storable-2.410.0-r1) On review some packages don't even have the indicated version in portage, like perl-core/ExtUtils-Install. The only available version is 1.540.0-r1. perl-core/Storable is blocked by the virtual? Why not fix it so it installs the virtual package. Perl is NOT the only package seeing these issues! Thanks for your time.
(In reply to bschnzl from comment #13) > I don't know where the responsibility lays. Frankly I don't care. I am > seeing way too many "blocks" and other emerge stoppages on many machines. > This was pulled from a minimal recent install. [snip] > On review some packages don't even have the indicated version in portage, > like perl-core/ExtUtils-Install. The only available version is 1.540.0-r1. > perl-core/Storable is blocked by the virtual? Why not fix it so it installs > the virtual package. > > Perl is NOT the only package seeing these issues! > > Thanks for your time. A) Please don't abuse the stable request for this and further similar comments, but file a separate bug. B) Most likely this is not a bug but a configuration problem. See e.g. http://dilfridge.blogspot.de/2014/08/perl-in-gentoo-upgrading-pains-perl.html You can try the following commands: emerge --deselect --ask $(qlist -IC 'perl-core/*') emerge -uD1a $(qlist -IC 'virtual/perl-*')
(In reply to Andreas K. Hüttel from comment #14) > (In reply to bschnzl from comment #13) > > [snip] > > > On review some packages don't even have the indicated version in portage, > > like perl-core/ExtUtils-Install. The only available version is 1.540.0-r1. > > perl-core/Storable is blocked by the virtual? Why not fix it so it installs > > the virtual package. > > > > Perl is NOT the only package seeing these issues! > > > > Thanks for your time. > > A) Please don't abuse the stable request for this and further similar > comments, but file a separate bug. > > B) Most likely this is not a bug but a configuration problem. See e.g. > http://dilfridge.blogspot.de/2014/08/perl-in-gentoo-upgrading-pains-perl.html > > You can try the following commands: > emerge --deselect --ask $(qlist -IC 'perl-core/*') > emerge -uD1a $(qlist -IC 'virtual/perl-*') A) If this is "stable" (emerge requiring in depth review and analysis), how are lesser users supposed to upgrade? B) These are newly installed minimal machines (No X, headless). It is their first update (2 weeks). There is no PERL development on these machines. What configuration there is was destributed in portage snapshots. If I can fix it with a command, why isn't that in the ebuild? This is a critique on the status of this bug.
> A) If this is "stable" (emerge requiring in depth review and analysis), how are lesser users supposed to upgrade? Unfortunately, there's no way to indicate to portage "This ebuild should be removed even if its in your worldfile". The worldfile takes precedence, coercing portage into choosing the wrong path. Which basically means no matter what we indicate with dependencies, either you'll have a dependency explosion in such a circumstance, or you'll have a silently broken system. Because for some virtuals, 'dev-lang/perl' is the only provider for that virtual, and may even be the only possible provider of a specific version. And if a virtual is satisifed by perl, then the corresponding perl-core/* MUST be removed, ( its a perl implementation detail issue ), or the virtual will be misleading things that depend on it about what version is available. Yes, we've presently got '||( perl perl-core/* )' in there, but that's not the issue. The issue is: !>perl-core/ ... !<perl-core/ ... Which says, "in there is a perl-core/Foo, thats ok, otherwise, remove perl-core/Foo". We *could* simplify this condition in some cases where there are no perl-core/* for a given version to !perl-core/Foo However, that would explode the same way you see now, portage would refuse to remove perl-core/Foo due to the worldfile, and portage would try to find some other way to make it happen, and you'd be back here filing a bug, and it would increase the maintenance for us to do it that way with no real benefit. > B) These are newly installed minimal machines (No X, headless). It is their first update (2 weeks). There is no PERL development on these machines. What configuration there is was destributed in portage snapshots. > If I can fix it with a command, why isn't that in the ebuild? > This is a critique on the status of this bug. Moves are afoot to patch perl to indicate this situation in advance where possible, but we can't *fix* the problem from within portage. Your world file is your control, you edit it, or your package manager does in response to 'pkg-move' updates. Not us, and there's no way to tell portage "delete this atom from the users worldfile for them", nor would I want such a behaviour. =~ Basically we're in a case where portage *is* stable, but user configuration is breaking things. User configuration can break a lot of things, but its not really gentoo's responsibility to fix user misconfiguration.
(In reply to Kent Fredric from comment #16) {snip} > > > B) These are newly installed minimal machines (No X, headless). It is their first update (2 weeks). There is no PERL development on these machines. What configuration there is was destributed in portage snapshots. > > > If I can fix it with a command, why isn't that in the ebuild? > > > This is a critique on the status of this bug. > > Moves are afoot to patch perl to indicate this situation in advance where > possible, but we can't *fix* the problem from within portage. > > Your world file is your control, you edit it, or your package manager does > in response to 'pkg-move' updates. > > Not us, and there's no way to tell portage "delete this atom from the users > worldfile for them", nor would I want such a behaviour. > > =~ Basically we're in a case where portage *is* stable, but user > configuration is breaking things. User configuration can break a lot of > things, but its not really gentoo's responsibility to fix user > misconfiguration. I have been working with Gentoo for over a decade - in production. I am familiar with the complexities. I am all too familiar with compounding errors from choices and "misconfigurations". I even took a shot at arch testing, which died because I was getting paid to do other things. I am still paid to do other things. I can see that Gentoo Devs are dedicated to producing a stable distro - ONLY. Of any OS, Gentoo asserts the "right" to compound prior configuration problems for market advantage least. That is why I am here. I pointed out two issues with this perl release If I had dug, I could have come up with more. Please take steps to tighen up the entire portage ship! I will duck out now. You will do what you will do.
arm stable
Stable for HPPA.
ppc64 stable
ppc stable
ia64 stable
x86 stable
sparc stable. Closing.