Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 504786 (perl-5.18-stable) - =dev-lang/perl-5.18.2-r1 and related virtuals stabilization
Summary: =dev-lang/perl-5.18.2-r1 and related virtuals stabilization
Status: RESOLVED FIXED
Alias: perl-5.18-stable
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Perl team
URL:
Whiteboard:
Keywords: STABLEREQ
Depends on: 523578 513406 517894 517898 517906 518032 518432 518470 518490 519186 519272 519458 519524 519606 520014 520848 520850 521824 525152 525306
Blocks: CVE-2012-6329 496422
  Show dependency tree
 
Reported: 2014-03-16 10:59 UTC by Vladimir Smirnov (RETIRED)
Modified: 2014-11-05 12:39 UTC (History)
3 users (show)

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


Attachments
list of packages to be stabilized, v1 (perl-5.18-stablelist-v1.txt,3.46 KB, text/plain)
2014-07-23 08:25 UTC, Andreas K. Hüttel
Details
list of packages to be stabilized, v2 (perl-5.18-stablelist-v2.txt,3.57 KB, text/plain)
2014-07-23 10:49 UTC, Andreas K. Hüttel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Smirnov (RETIRED) gentoo-dev 2014-03-16 10:59:23 UTC
Tracker for perl 5.18 related bugs.

Reproducible: Always
Comment 1 Zentoo 2014-04-02 14:15:38 UTC
Depends on https://bugs.gentoo.org/show_bug.cgi?id=506374
Comment 2 Andreas K. Hüttel archtester gentoo-dev 2014-07-23 08:24:46 UTC
Nothing left to do here, so preparing the stabilization request.
Comment 3 Andreas K. Hüttel archtester gentoo-dev 2014-07-23 08:25:44 UTC
Created attachment 381406 [details]
list of packages to be stabilized, v1

First, untested version of the stabilization list attached. See the list for instructions.
Comment 4 Andreas K. Hüttel archtester gentoo-dev 2014-07-23 10:49:52 UTC
Created attachment 381424 [details]
list of packages to be stabilized, v2

Add needed perl-core package
Comment 5 Andreas K. Hüttel archtester gentoo-dev 2014-07-23 10:52:45 UTC
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.
Comment 6 Andreas K. Hüttel archtester gentoo-dev 2014-07-24 08:24:06 UTC
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.
Comment 7 Tobias Klausmann (RETIRED) gentoo-dev 2014-07-24 09:49:44 UTC
(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.
Comment 8 Andreas K. Hüttel archtester gentoo-dev 2014-07-24 10:28:29 UTC
(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.
Comment 9 Andreas K. Hüttel archtester gentoo-dev 2014-07-26 18:13:28 UTC
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.]
Comment 10 Andreas K. Hüttel archtester gentoo-dev 2014-07-26 18:14:01 UTC
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.]
Comment 11 Tobias Klausmann (RETIRED) gentoo-dev 2014-07-28 15:23:13 UTC
I stabilized perl-tk (dependent bug) just now and Alpha is done.
Comment 12 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-07-28 17:48:21 UTC
amd64 stable
Comment 13 bschnzl 2014-08-22 14:42:00 UTC
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.
Comment 14 Andreas K. Hüttel archtester gentoo-dev 2014-08-23 13:59:57 UTC
(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-*')
Comment 15 bschnzl 2014-08-23 15:58:13 UTC
(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.
Comment 16 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2014-08-24 02:18:55 UTC
> 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.
Comment 17 bschnzl 2014-08-24 14:28:20 UTC
(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.
Comment 18 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-08-31 17:55:47 UTC
arm stable
Comment 19 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-17 14:03:35 UTC
Stable for HPPA.
Comment 20 Agostino Sarubbo gentoo-dev 2014-09-21 11:11:27 UTC
ppc64 stable
Comment 21 Agostino Sarubbo gentoo-dev 2014-09-21 11:22:37 UTC
ppc stable
Comment 22 Agostino Sarubbo gentoo-dev 2014-09-22 09:59:36 UTC
ia64 stable
Comment 23 Agostino Sarubbo gentoo-dev 2014-09-22 10:12:52 UTC
x86 stable
Comment 24 Agostino Sarubbo gentoo-dev 2014-09-23 09:59:07 UTC
sparc stable. Closing.