On 27 September 2013 08:02, Martin Vaeth <va...@mathematik.uni-wuerzburg.de>wrote:
> For those which are provided by perl itself, you could have > a corresponding useflag of dev-lang/perl and make a use dependency: > If the main perl tarball does not provide the package, the perl ebuild > can pull in the corresponding package as a dependency. > That would be horrible. You'd have a massive list of USE flags, and you'd want *all* of them by default, and they'd have to pull the deps as PDEPENDS, because its impossible to have them as DEPENDS. And that would mean: X package wants Module::Build, so not only do you have to declare a dependency on Module::Build somehow, thats controlled by a USE flag, so maybe rebuild the entirety of Perl, just to install one thing that can be installed seperately from Perl. Also, instead of having the logical thing when Module::Build does get fully removed from perl, that we can simply remap the virtual to always pull from perl-core/Module-Build, we'd have to re-write every package in tree that used Module-Build. I was asking for solutions that reduce work, not increase it =p And when you wanted a specific version of a "dual life" module, you'd be completely out of luck. ( This is a problem with Module::Build, Test-Simple and ExtUtils::MakeMaker, because people regularly depend on specific versions of those things ) > This is appropriate if > something really needs a newer version, but not just because something > *must* depend on the virtual only because some perl versions do > not provide it. Worse than that I'm afraid, things that are virtualled are virtualled because upstream can and will depend on a specific version of that thing, and time to time, those versions are available only via CPAN, not via the present version of Perl And other times, upstream will depend on an explicit version which is available only in specific versions of perl, and virtuals are the only tool we have at present to mitigate these problems. And more, there is the growing list of modules that may be presently installed with perl, but are slated to stop being shipped with perl in a future release of perl. That means things that don't depend on the virtuals *now* will be broken when that version of perl ships, and its much, much easier to use the virtuals to resolve this problem, as opposed to tracking down all the modules that need to be fixed, and inlining a big list of conditional dependencies in each and every module that uses such a package. -- Kent
