Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 374149 - Moose-2.1.0 conflicts with all existent versions of File-ChangeNotify, MooseX-Params-Validate, and MooseX-SemiAffordanceAccessor
Summary: Moose-2.1.0 conflicts with all existent versions of File-ChangeNotify, MooseX...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Perl team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-05 15:54 UTC by chris salch
Modified: 2014-10-11 08:52 UTC (History)
1 user (show)

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


Attachments
Corrected Ebuild (Moose-2.1.0-r1.ebuild,2.56 KB, text/plain)
2011-07-05 15:59 UTC, chris salch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chris salch 2011-07-05 15:54:14 UTC
I've run into this issue several times now.  It appears that there are conflicts defined in the Moose ebuild that require versions of the specified packages which do not currently exist on CPAN.  If you have these three installed via g-cpan, it is impossible to upgrade Moose.

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild     U  ] dev-perl/Moose-2.1.0 [2.0.800-r1] USE="-test" 647 kB [1=>0]
[blocks B      ] <=dev-perl/File-ChangeNotify-0.150 ("<=dev-perl/File-ChangeNotify-0.150" is blocking dev-perl/Moose-2.1.0)
[blocks B      ] <=dev-perl/MooseX-Params-Validate-0.50 ("<=dev-perl/MooseX-Params-Validate-0.50" is blocking dev-perl/Moose-2.1.0)
[blocks B      ] <=dev-perl/MooseX-SemiAffordanceAccessor-0.50 ("<=dev-perl/MooseX-SemiAffordanceAccessor-0.50" is blocking dev-perl/Moose-2.1.0)

Total: 1 package (1 upgrade), Size of downloads: 647 kB
Conflict: 3 blocks (3 unsatisfied)
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-perl/Moose-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
    Moose

  (dev-perl/MooseX-SemiAffordanceAccessor-0.09::local_overlay, installed) pulled in by
    dev-perl/MooseX-SemiAffordanceAccessor required by @selected

  (dev-perl/File-ChangeNotify-0.20::local_overlay, installed) pulled in by
    dev-perl/File-ChangeNotify required by @selected

  (dev-perl/MooseX-Params-Validate-0.16::local_overlay, installed) pulled in by
    dev-perl/MooseX-Params-Validate required by @selected


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

Reproducible: Always

Steps to Reproduce:
1. Install any of the three packages listed in the subject via g-cpan
2. Attempt to install Moose-2.1.0

Actual Results:  
These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild     U  ] dev-perl/Moose-2.1.0 [2.0.800-r1] USE="-test" 647 kB [1=>0]
[blocks B      ] <=dev-perl/File-ChangeNotify-0.150 ("<=dev-perl/File-ChangeNotify-0.150" is blocking dev-perl/Moose-2.1.0)
[blocks B      ] <=dev-perl/MooseX-Params-Validate-0.50 ("<=dev-perl/MooseX-Params-Validate-0.50" is blocking dev-perl/Moose-2.1.0)
[blocks B      ] <=dev-perl/MooseX-SemiAffordanceAccessor-0.50 ("<=dev-perl/MooseX-SemiAffordanceAccessor-0.50" is blocking dev-perl/Moose-2.1.0)

Total: 1 package (1 upgrade), Size of downloads: 647 kB
Conflict: 3 blocks (3 unsatisfied)
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-perl/Moose-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
    Moose

  (dev-perl/MooseX-SemiAffordanceAccessor-0.09::local_overlay, installed) pulled in by
    dev-perl/MooseX-SemiAffordanceAccessor required by @selected

  (dev-perl/File-ChangeNotify-0.20::local_overlay, installed) pulled in by
    dev-perl/File-ChangeNotify required by @selected

  (dev-perl/MooseX-Params-Validate-0.16::local_overlay, installed) pulled in by
    dev-perl/MooseX-Params-Validate required by @selected


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

Expected Results:  
Moose to install

The three packages in question are currently not in portage but install cleanly via g-cpan.  The issue is that the Moose ebuild has incorrect versions for them listed in the Conflicts section.
Comment 1 chris salch 2011-07-05 15:59:07 UTC
Created attachment 279173 [details]
Corrected Ebuild

The attached ebuild covers the module versions that I have installed.  I have not tested to see if any of the other listed conflicts have actual CPAN versions.
Comment 2 Torsten Veller (RETIRED) gentoo-dev 2011-07-08 17:11:22 UTC
We are currently changing the version scheme of our perl packages to dotted-decimal versions. (This help with version order problems with our package manager.)
That means your dev-perl/File-ChangeNotify-0.20::local_overlay would be 0.200.0 in the tree.

The required versions exist on CPAN.

But g-cpan doesn't do the version translation right now. (But it installs the modules to a different category per default, what was it? perl-gcpan?)

Consider using/working on our perl-experimental overlay[1,2] from layman. It contains a number of MooseX modules too.


[1] http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git
[2] https://github.com/gentoo-perl/perl-experimental
Comment 3 chris salch 2011-07-08 18:15:02 UTC
(In reply to comment #2)
> We are currently changing the version scheme of our perl packages to
> dotted-decimal versions. (This help with version order problems with our
> package manager.)
> That means your dev-perl/File-ChangeNotify-0.20::local_overlay would be 0.200.0
> in the tree.
> 
> The required versions exist on CPAN.
> 
> But g-cpan doesn't do the version translation right now. (But it installs the
> modules to a different category per default, what was it? perl-gcpan?)
> 
> Consider using/working on our perl-experimental overlay[1,2] from layman. It
> contains a number of MooseX modules too.
> 
> 
> [1] http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git
> [2] https://github.com/gentoo-perl/perl-experimental

I haven't attempted to use the perl-experimental overlay, and I currently have g-cpan setup to create ebuilds in the dev-perl namespace.  I found that using the other namespace caused problems.  Do you know if work is being done to update g-cpan?

Chris S.
Comment 4 Kent Fredric (IRC: kent\n) gentoo-dev 2011-07-10 01:04:33 UTC
"and I currently have g-cpan setup to create ebuilds in the dev-perl namespace."

I'd strongly suggest not doing that, it virtually guarantees future problems when we introduce something ourselves which you yourself introduced earlier but with an incompatible versioning scheme.

"I found that using the other namespace caused problems."

For example? I would imagine those specific bugs have bug ID's you can refer to? That'd be much more helpful long-term =)

> Do you know if work is being done to update g-cpan?

There's also a different tool similar to g-cpan for generating ebuilds, CPANPLUS::Dist::Gentoo  ( available as dev-perl/CPANPLUS-Dist-Gentoo on the aforementioned overlay ), which may prove to be of some value to you.

Personally myself, I do just as tove suggests, I hand-craft ebuilds ( mostly generated from a simple template ), which is for the most part just specifying which dependencies to use, and letting the eclass handle the rest. And when it works for me, it gets committed to the overlay =)

If I'm feeling too lazy to write an ebuild or I'm not sure if I like the module or not, I'm inclined to use local::lib + cpanm ( dev-perl/local-lib , dev-perl/App-cpanminus  , both in the overlay ), which is almost equal to "its already in portage" in terms of convenience. 

( I'm almost tempted to suggest local-lib should be in the main tree, and perhaps when cpanm's development slows down a bit and stops growing in terms of feature-sets, it might also be a good addition to the main tree )

But we really could do with a few more willing hands who understand basic bash/git/perl to help maintain that overlay.

Hope this helps =).

Kent.
Comment 5 chris salch 2011-07-10 03:47:03 UTC
(In reply to comment #4)
> "and I currently have g-cpan setup to create ebuilds in the dev-perl
> namespace."
> 
> I'd strongly suggest not doing that, it virtually guarantees future problems
> when we introduce something ourselves which you yourself introduced earlier but
> with an incompatible versioning scheme.
> 
> "I found that using the other namespace caused problems."
> 
> For example? I would imagine those specific bugs have bug ID's you can refer
> to? That'd be much more helpful long-term =)

Unfortunately, I did not file bugs as I could not really see how the problems were the fault of a bug in portage or g-cpan.  I ran into several situations where a g-cpan created ebuild latter caused conflicts with ebuilds that were added to the protage tree at a latter date.  These would be caught during emerge as file conflicts with no obvious automatic means of resolving them.  At the time, I was installing a package with many dependencies ( I think it was a version of catalyst . . .) and I found myself with a rather annoying non-trivial upgrade path.  Having g-cpan create ebuilds in dev-perl, using a local overlay, avoided this problem and allowed for a newer version to be added via emerge --sync or g-cpan to be a reasonably clean upgrade path from the previous one without having to modify large numbers of ebuilds by hand.  Of course, it is entirely possible that this was simply masking other potential problems, like what I'm running into now.

> 
> > Do you know if work is being done to update g-cpan?
> 
> There's also a different tool similar to g-cpan for generating ebuilds,
> CPANPLUS::Dist::Gentoo  ( available as dev-perl/CPANPLUS-Dist-Gentoo on the
> aforementioned overlay ), which may prove to be of some value to you.
> 
> Personally myself, I do just as tove suggests, I hand-craft ebuilds ( mostly
> generated from a simple template ), which is for the most part just specifying
> which dependencies to use, and letting the eclass handle the rest. And when it
> works for me, it gets committed to the overlay =)

I don't mind doing ebuilds by hand, when I need to.  Though I haven't built very many.  I don't like doing dependency chains by hand if I can avoid it.  g-cpan looked like a nice way to get cpan like interaction nicely coupled with portage.  

> 
> If I'm feeling too lazy to write an ebuild or I'm not sure if I like the module
> or not, I'm inclined to use local::lib + cpanm ( dev-perl/local-lib ,
> dev-perl/App-cpanminus  , both in the overlay ), which is almost equal to "its
> already in portage" in terms of convenience. 
> 
> ( I'm almost tempted to suggest local-lib should be in the main tree, and
> perhaps when cpanm's development slows down a bit and stops growing in terms of
> feature-sets, it might also be a good addition to the main tree )

That's an interesting module that I hadn't seen before.  I've used an approach similar to that a couple of times before.  I'll have to take a closer look at it if I get the chance.

> 
> But we really could do with a few more willing hands who understand basic
> bash/git/perl to help maintain that overlay.
> 
> Hope this helps =).
> 
> Kent.

What are the requirements/needs?  As a note, if this is related to a change in the way version numbers are recorded in portage that probably means I need to change my practices or come up with a fix for g-cpan.  Which means it is probably safe to close this out.

Chris S.
Comment 6 Andreas K. Hüttel gentoo-dev 2014-10-11 08:52:18 UTC
Ugh. That's about as invalid as it gets.