Sorry if this is duplicate: I repost since I cannot see it after a few hours.
Kent Fredric <[email protected]> wrote: > > On 27 September 2013 08:02, Martin Vaeth ><[email protected]>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. Why is this horrible? Perhaps there is a misunderstanding. You would need only those useflags which are possibly not provided by the corresponding perl version: The package dependent on a feature could just use e.g. DEPEND=dev-lang/perl[perl_module_Term_ANSIColor(+)] And concerning the number of use-flags, it might be worth thinking about a USE_EXPAND="perl_module". > so maybe rebuild the entirety of Perl, just to install one thing that > can be installed seperately from Perl. If the common flags are enabled by default, this would only involve users who have a serious reason (e.g. space issues) to disable some modules. Yes, these users would have to rebuild unnecessarily if they change their mind later on. I would compare disabling these modules with something like setting USE=minimal for other packages; users should know what they are doing if they use this. > 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. My idea is to keep this in the perl ebuilds "forever": According to the perlversions which are still in the tree, it will take dozens of years until all perl versions providing Module-Build have vanished from the tree, and only afterwards it makes sense to think about such a change. > This is a problem with Module::Build, Test-Simple > and ExtUtils::MakeMaker, because people regularly depend on specific > versions of those things My suggestion was explicitly about modules for which ebuilds do not require an explicit version. For those few(!) modules for which particular versions are needed, perhaps the virtual might be kept. Alternatively, for such cases it might make sense to depend directly on the package, since the probability to save duplicate installation in such a case is rather low, anyway. > 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 As mentioned above, this involves only a relatively small number of virtuals. Here is how I got the list: eix --print-all-depends | sed 's/"//g' \ grep -o '[^ ]*virtual/perl-[^ ]*-[0-9][^ ]*' |sort -u And I guess that in this list of (for the main tree, but even with eix -Z ... the list is hardly longer) 62 packages actually many fall into the class where the minimal version is provided by current stable perl version anyway so that actually the minimal version dependency is redundant. > 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 > [...] and inlining a big list of > conditional dependencies in each and every module that uses such a package. I was not suggesting inlining the list into the dependency but only inlining the USE-flag into the (single) perl ebuild. Currently if I have a package which needs e.g. Term-ANSI-Color, but not in a particular version, if I do not want to install an unnecessary duplicate version, I must inline a dependency like || ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) and possibly change this if perl-5.20 does no longer contain perl-Term-ANSIColor.
