Please stabilize together, target "amd64 hppa ppc x86" dev-perl/HTTP-BrowserDetect-2.80.0 dev-perl/Devel-Hide-0.0.900 dev-perl/Path-Tiny-0.61.0 dev-perl/Taint-Runtime-0.30.0-r1 dev-perl/Test-FailWarnings-0.8.0 dev-perl/Unicode-UTF8-0.600.0 dev-perl/Variable-Magic-0.580.0 perl-core/JSON-PP/JSON-PP-2.273.0 virtual/perl-JSON-PP/perl-JSON-PP-2.273.0
amd64 stable
x86 stable
ppc stable
(In reply to Andreas K. Hüttel from comment #0) > perl-core/JSON-PP/JSON-PP-2.273.0 > virtual/perl-JSON-PP/perl-JSON-PP-2.273.0 Really?
(In reply to Jeroen Roovers from comment #4) > (In reply to Andreas K. Hüttel from comment #0) > > perl-core/JSON-PP/JSON-PP-2.273.0 > > virtual/perl-JSON-PP/perl-JSON-PP-2.273.0 > > Really? No, I'm just making up work for you. :o) Kidding... Some of the newer CPAN modules need parts of Perl more modern than our stable 5.20 (as this one here). Other parts of CPAN must be updated before we stabilize 5.22 (otherwise incompatibilities lead to ugly bugs). So the strategy I picked was "first bring all dev-perl/* up to current, then stabilize Perl 5.22". Has advantages and disadvantages, but changing it after >50% of the work makes no sense. Summary, yes please do stabilize it.
Apologies in advance if stating the obvious, but this strategy breaks @world update on stable systems. ie. Stable ebuilds depending on unstable ebuilds. Here is the current list of stable packages to add to package.mask for stable systems to be able to @world update: >=virtual/perl-CPAN-Meta-2.150.1 >=virtual/JSON-PP-2.273.0 >=virtual/perl-Module-Metadata-1.0.26 >=virtual/perl-Test-Simple-1.1.14 If dev-lang/perl-5.22 is to be stabilised, why can it not all be rolled out as one? If there are some dependency changes and/or merge order issues would it not be best solved by using DEPEND and version blocks? Cheers :)
(In reply to Rick Harris from comment #6) > Apologies in advance if stating the obvious, but this strategy breaks @world > update on stable systems. No, it doesn't. The virtual is perfectly fulfilled by perl-core/JSON-PP, which is also in above list. > Here is the current list of stable packages to add to package.mask for > stable systems to be able to @world update: [snip] I'm not sure what is wrong in your particular case; on a hunch, maybe you should upgrade portage to latest stable 2.2.26 first.
(In reply to Andreas K. Hüttel from comment #7) > (In reply to Rick Harris from comment #6) > > Apologies in advance if stating the obvious, but this strategy breaks @world > > update on stable systems. > > No, it doesn't. The virtual is perfectly fulfilled by perl-core/JSON-PP, > which is also in above list. > > > Here is the current list of stable packages to add to package.mask for > > stable systems to be able to @world update: > [snip] > > I'm not sure what is wrong in your particular case; on a hunch, maybe you > should upgrade portage to latest stable 2.2.26 first. Many thanks. Upgrading from sys-apps/portage-2.2.20.1 to sys-apps/portage-2.2.26 fixed the problem and the packages resolve themselves now without resorting to masking. So why wouldn't an 'emerge @world' update portage first if it needs to be?
(In reply to Rick Harris from comment #8) > > So why wouldn't an 'emerge @world' update portage first if it needs to be? Bug 577546... but that's offtopic here.
RepoMan scours the neighborhood... dependency.bad [fatal] 1 virtual/perl-JSON-PP/perl-JSON-PP-2.273.0-r1.ebuild: RDEPEND: hppa(default/linux/hppa/13.0) ['=dev-lang/perl-5.24*'] dependency.unknown 1 virtual/perl-JSON-PP/perl-JSON-PP-2.272.30.ebuild: RDEPEND: ~perl-core/JSON-PP-2.272.30 Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. RepoMan sez: "Make your QA payment on time and you'll never see the likes of me."
