Kent Fredric <kentfred...@gmail.com> wrote: >> > So are you basically suggesting that for dual life modules, we simply > ignore that they're dual-lifeable, and then when upstream splits a package > from core so that its no longer dual life, that we simply ignore that too, > and fake it still being core for the forseeable future?
Yes, this is the idea. (Although I must admit that meanwhile I prefer the ebuild idea). > IMO, really, the uses would be forced enabled for all users, because they > should never be disabled. If they're part of the Perl built itself, they > should get installed. Period. Exactly: Those which are part of the Perl built itself would not have a useflag at all. Only for those which are *not* in part of the current perl built you would have a useflag. For instance, USE=Time-Piece would not occur in the perl-5.10* ebuilds but in all other perl ebuilds in the form PDEPEND="Time-Piece? ( perl-core/Time-Piece )" Packages needing Time-Piece would then just RDEPEND="dev-lang/perl[Time-Piece(+)]" and would thus implicitly get the correct dependency. Once the translation is done, the only place where maintenance is needed are the perl-ebuilds. > But why would you "depend on the perl-provided version" Many packages only need the basic functionality of a library, not a particular version. The problem is that something like RDEPEND="virtual/perl-..." implicitly depends on a particular version, namely the highest one which is currently stable/unstable for your architecture instead of the one which avoids unnecessary installation. > Are you saying that, if something is provided by perl core, that we must > never update to a cpan version? If the user explicitly requires a particular package or if a package explicitly depends on a certain minimal version, the upgrade will be automatic. However, if there is no need (dependency or explicit user request) for a particular version, the installed version should be sufficient. > You realise thats breaking how upstream thinks toolchains work right? Upstream always thinks that you have to use the most current unstable version of everything. This is not only true for perl but also for every other bigger project (texlive or many others come to mind). It is the distribution's task to give a more stable user experience. > You're missing a very important point: Every single line of output without > the uniq constraint is a package depending on a virtual. This is not the case, but this need not be discussed here; we agree that the number of *packages* depending on virtual versions is large. > The virtual is managing the need to have a conditional dependency based on > the version of perl installed. > > You would need to ,without virtuals, modify *EVERY* ebuild containg a > dependency on a virtual, to contain the respective conditional dependency > enshrined in the virtual. No. You just keep those few virtuals for which the packages explicitly depend on the version. The remaining ones - for which the version plays no role - are replaced *once* by the corresponding USE-dependency. (However, as said above, I meanwhile prefer the eclass idea; with the eclass you could treat both cases - those depending on a particular version and those depending only on *some* version - in the same way and even omit all virtuals.) > Not sure about you, but the idea of modifying 20,000 lines of code instead > of 1, is something I don't look on fondly. Both solutions would require only *once* to modify the dependencies. After the transfer is done, you only have to modify 1 line >>|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) >> > >> > That is plain wrong imo. You're prematurely optimising the dependency. >> >> The alternative is to pull in a duplicated installation which is >> completely superfluous, since it is already installed by most >> perl versions, > > You're not though. Thats the point. Virtuals are doing exactly that. > They're just doing it in the virtual instead of your ebuild. Only if there would be only *one* version of the corresponding virtual. With *more* virtual versions as it is currently, it is rather likely that an unneeded version of perl-core/Term-ANSIColor is pulled it. > If you are installing virtual Y version X, if you are on a version of Perl > that contains Y version X, the virtual avoids the need to install the > respective perl-core/X. But if I am just installing virtual Y, version does not matter, I will likely get virtual Y, versions X+Z although version X is already there and thus version Z would not be needed. > If you don't like that packages get updated, and pull newer-that-core > versions of things, there's nothing to stop you grepping virtual/perl-*, > and masking versions that don't match an "=your current version of perl". This is a lazy excuse: Instead of producing proper dependencies you are shifting the work to the user. In fact, I did this work in the beginning, but not only is this a lot of work for every perl upgrade (which is not so trivial to script), you also need a lot of exceptions where the mask is not possible, because some package needs a newer version. For e.g. overlays which I provide to users, I do not want to shift *my* work on the user's side and thus have to write clumsy dependencies without virtual/... If you use the ebuild or USE-idea you would get correct dependencies which do not require the user to hack around and mask things only to avoid unnecessary installations. >> I'd also sooner consider attempting to eliminate the need for virtuals by >> > unilaterally depending on perl-core/* , and vivifying perl-core/ from >> > dev-lang/perl sources as needed. >> >> This breaks proper support for building/using binary packages for >> perl-core/* since the installed files will depend on which packages >> are installed at build-time. > > I'm not really sure what you're sayng here. Sorry :/ If you are writing an ebuild X whose action of src_install() depends implicitly on the installed perl-version and the user executes emerge --buildpkg=y X on one machine and emerge --usepkg X on another machine (or at a later time) he will run into problems without a warning if the perl versions of that two machines are not the same (or have changed meanwhile) when the two commands are executed. Roughly speaking, you build an implicit dependency into the *.tbz2 file which portage is not aware of and will not warn the users about.
