Kent Fredric <kentfred...@gmail.com> wrote:
> --001a11336248343a2604e7770011
> Content-Type: text/plain; charset=UTF-8
>
> On 28 September 2013 23:36, Martin Vaeth
><va...@mathematik.uni-wuerzburg.de>wrote:
>
>>
>> Concerning the eclass idea which was already mentioned and
>> which is perhaps even better than my suggeestion from the
>> other posting, since it avoids some of the disadvantages:
>>
>> > by having an eclass that translates a special variable, say,
>> > PERL_MODULE_COREDEPS="Term::ANSIColor@3.2" or something
>>
>> I would keep it simple like
>>
>> RDEPEND="$(perl-dep Term-ANSIColor)
>> $(perl-dep ">=Module-Load-0.240.0")"
It would have been wiser to suggest here the syntax
perl-core/Term-ANSIColor and perl-core/Module-Load-0.240.0,
respectively so that the category need not be fixed to
"perl-core".
>>
>> which would then translate into something like
>>
>> RDEPEND="( || ( ( >=perl-5.12 <=perl-5.18.1 ) perl-core/Term-ANSIColor )
>> || ( >=perl-5.18 >=perl-core/Module-Load-0.240.0 )"
>>
>> (or "|| ( ( perl-5.12* perl-5.14* ...
>> || ( perl-5.18* ...)" -
>> subject to further discussion)
>
>
> The most annoying thing about that would be the implementation details.
Why? One of use probably misunderstand something:
> Every perl we release, we have to manually update "something", "somewhere"
> in a location *other* than the perl ebuild itself.
If you decide to use the eclass, then with each perl release
you would have to update the data in the eclass - namely the LIST of
provided packages for that new version. Something like
LIST_perl5.18=(
perl-core/Term-ANSIColor-4.20
perl-core/...-...
dev-perl/...-...
!perl-core/X-Y
!!perl-core/X-Y
)
LIST_perl5.16=(
)
...
AVAILABLE_PERLS="5.18 5.16 ..."
where the special symbols ! means that version perl-core/X-Y is
not available in the tree and !! means that perl-core/X is not
available in the tree (in no version).
These LISTs are all which you have to update for new perl versions.
The rest should be handled by the logic of the eclass, and I do not
see why this should be hard to do:
1.
If perl-dep is called with the argument
">=category/package-version",
">category/package-version",
"<=category/package-version",
"<category/package-version",
"=category/package-version", or
"~category/package-version",
the function just output into || ( ... ) all perl versions which provide
a matching package according to LIST, followed by the passed argument
(the latter is skipped, if masked by ! or !! according to one LIST).
In case of "<=" or "<" in addition the blocker
"!>category/package-version" or "!>=category/package-version"
is output (unless masked by ! or !!).
2.
If perl-dep is called with the argument
"catogory/package"
(without a version) the function just adds into || ( ... ) all
perl versions which provide the package and in addition ends with
the passed argument (unless masked by !!).
Implementation of that function is rather simple once you have
a version comparison function (I do not remember in the moment
whether this is already available in some eclass or will be
only available the next EAPI).
Of course, the output could be optimized by omitting the "|| ( )" symbols
if there is only one match etc.
> Which means that instead of simply modifying perl's .ebuild, and walking
> the contents of module::corelist and saying "This version provides X
> version Y", one must instead have a way to reorient that data from the
> perspective of dependencies.
Why? You update the eclasses LIST variables in one place when a new
version of perl comes out. All functions needing a perl
package use the perl-dep function (which means a one-shot change for
all packages needing a perl package; for packages in the
tree this can be done by the "script" I mentioned).
> The best solution I presently have for this problem, would be to have
> a PROVIDES-${PV}.json file in every package under files/
Not under files but in the eclass, and the rest of the
work is done by the perl-dep function.
