Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 242172 - dev-perl/XML-Encoding does not need XML-Parser at build-time, beside for testing
Summary: dev-perl/XML-Encoding does not need XML-Parser at build-time, beside for testing
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Perl team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-15 10:39 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2010-08-24 20:16 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2008-10-15 10:39:12 UTC
Seems like this is a common condition, which I also guess is well known, but would it be possible to express these dependencies in a specific way? I ask because it makes my kind of testing harder since it will fail to -B the packages since they are missing dependencies...

Thanks,
Diego
Comment 1 Torsten Veller (RETIRED) gentoo-dev 2008-10-22 09:08:27 UTC
(In reply to comment #0)
> Seems like this is a common condition, which I also guess is well known, but
> would it be possible to express these dependencies in a specific way? I ask
> because it makes my kind of testing harder since it will fail to -B the
> packages since they are missing dependencies...

I don't understand what you want. It is also not clear why -B might fail in this case. I guess the XML-* stuff in the summary is just an example? Do you want us to move everything to RDEPEND only that is not needed to build (beside some check in the Makefile)?

Is it something like:
- DEPEND="dev-perl a b c"
+ RDEPEND="a b c"
+ DEPEND="dev-perl test? ( a b )"
and probably also fix the Makefile?

I guess we don't have the ressources for these changes currently.
Comment 2 Torsten Veller (RETIRED) gentoo-dev 2010-01-08 13:22:19 UTC
I still don't understand the problem.
Comment 3 Doktor Notor 2010-03-13 11:30:35 UTC
Dunno, but this looks like completely invalid bug in the first place. With 2.07 you get this in Makefile.PL

WriteMakefile(
              NAME         => 'XML::Encoding',
              dist         => {COMPRESS => 'gzip', SUFFIX => '.gz'},
              VERSION_FROM => 'Encoding.pm',
              PREREQ_PM    => {XML::Parser => 2.18},
              EXE_FILES    => [qw(bin/compile_encoding bin/make_encmap)],
              @extras
             );

About time to close this "bug"?
Comment 4 Torsten Veller (RETIRED) gentoo-dev 2010-08-24 07:16:38 UTC
I don't know what to do with this bugreport...
Comment 5 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2010-08-24 20:16:51 UTC
I don't think this is much of a valid bug. 

Firstly:

The configuration script ( Makefile.PL ) does not know the difference between "build" and "run" time, especially not "test" time, so therefor will possibly fail/warn in the event its not made happy, so our dependencies are kind-of futile in this case. 

In some of the more recent versions of Module::Install there is a supported test_depends, but no distinguishing between run_depends and build_depends. The other competitor, Module::Build has run and build deps, but no test_depends ( hopefully it will have these in an upcoming version though )

Because of this, lately I've been inclined to ignore my own desires for how I'd *like* test dependencies properly supported, I've just been writing new ebuilds as closely to the upstream Makefile.PL/Build.PL as possible. 

This involves also needlessly adding things that are really only test-only dependencies as build deps, because I don't have the resources to map test-only dependencies into the makefile.pl 

Likewise, the same goes for Prereq_pm , as annoying as it is having them as build_deps, upstream is implicitly treating them as build-deps also, and I don't feel justified making them rundeps in the ebuild without patching the build script to match.

And in all honesty, if you start ignoring PREREQ_PM as being an authoritative list of things that are build deps, then the *MAJORITY* of perl modules have practically *NO* build deps, but if the deps aren't there, $buildscript will moan about it causing false indications of failure. 

I'm no authority on this, but I'd like to just replicate upstream until their toolchain gets updated to work properly.