| Summary: | Moose-2.1.0 conflicts with all existent versions of File-ChangeNotify, MooseX-Params-Validate, and MooseX-SemiAffordanceAccessor | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | chris salch <emeraldd.chris> |
| Component: | [OLD] Development | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | emeraldd.chris |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Corrected Ebuild | ||
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.
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 (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. "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.
(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. Ugh. That's about as invalid as it gets. |
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.