| Summary: | =media-gfx/slic3r-1.2.9-r1: runtime requires multiple runtime dependencies not listed in ebuild. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Eric "me262" Mason <_me262> |
| Component: | Current packages | Assignee: | M. B. <tomboy64> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 3dprint, axs, perl, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=581892 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Eric "me262" Mason
2016-05-02 22:14:53 UTC
Is this on your attempt at a mixed-~arch system? Because the ebuild requires version 1.50.0 and perl is reporting that you have 1.30.0 installed. This really looks like it's due to a botched attempt at keywording and keeping installed the necessary versions of the slic3r depenencies. (In reply to Ian Stakenvicius from comment #1) > Is this on your attempt at a mixed-~arch system? Because the ebuild > requires version 1.50.0 and perl is reporting that you have 1.30.0 > installed. This really looks like it's due to a botched attempt at > keywording and keeping installed the necessary versions of the slic3r > depenencies. Right, so the ebuild has a typo, actually requiring 0.50.0 instead of 1.50.0; I'll fix that ASAP. commit 91fdee6efa5a28c056f36f83c24db2487ffa86c3 Author: Ian Stakenvicius <axs@gentoo.org> Date: Tue May 3 11:42:11 2016 -0400 media-gfx/slic3r: revbump to fix a couple of dependencies dev-perl/Encode-Locale had a typo in PV, fixed; also dropped the dependency of dev-lang/perl-5.22 since (A) it's not a real dependency and (B) it inhibits mixed-~arch installs if the user overlays perl-core/threads and perl-core/Socket to provide the necessary versions of those modules. Sub/Exporter/Progressive.pm is not a required dep that I can see, no match when I grepped the slic3r codebase. I also don't have it installed and don't run into any issues when using slic3r. Jeez before you mess up your whole system by playing around with Perl just run entire Perl system as ~arch... put in /etc/portage/package.keywords: dev-lang/perl virtual/perl-* perl-core/* Not more, not less. Anything else leads to breakage. Reopened. I seem to still be having problems after I downgraded back to 5.20 stable, that it still wants to pull perl 5.22. I opened up the ebuild and noted that the perl-threads virtual is coded as >=virtual/perl-threads-1.960.0 when in the portage tree stable is 1.930.0, testing is 2.10.0 same thing with >=virtual/perl-Socket-2.16.0 which has version 2.13.0 stable and 2.18.0 testing wondering if these are typos as well, as that's pulling in an unstable perl. (In reply to Eric "me262" Mason from comment #4) > Reopened. > > I seem to still be having problems after I downgraded back to 5.20 stable, > that it still wants to pull perl 5.22. Do you have all the other perl-core/ packages provided from the overlay? You must have them, or you must have 5.22, those are your only options. slic3r is ~arch, not 'arch'. > I opened up the ebuild and noted that the perl-threads virtual is coded as > >=virtual/perl-threads-1.960.0 > when in the portage tree stable is 1.930.0, testing is 2.10.0 That's because slic3r is testing. > same thing with > >=virtual/perl-Socket-2.16.0 > which has version 2.13.0 stable and 2.18.0 testing > > wondering if these are typos as well, as that's pulling in an unstable perl. That's because slic3r is testing, and it needs these newer dependencies ( which pull testing perl ) These are not "mistakes". The only mistake is mixing stable and testing and expecting it not to require manual effort. NB: At this point your needs fall into the view of "user support", not a bug. If you want, join #gentoo-perl and ask around and hopefully we can sort out any residual confusion you have ( and with a bit of luck I'll manage to seem less irrtable in the process ) There may be a bug somewhere, but until we're sure you've got the right system configuration where we can *expect* something to work, all you'll end up doing is filing bugs for user-configuration mistakes, ( which are not bugs ) |
