On Sat, Feb 12, 2005 at 09:34:59PM -0600, Chris Dolan wrote:
> --- The problem ---
>
> When a perl module is declared a variant, the .info file contains a
> line like this:
>
> Type: perl (5.8.0 5.8.1)
>
> The following questions arise for new modules:
>
> * Which versions should I include in the list?
> * When should the list change? And who should change them?
[maintainers list all kinds of combinations]
> Some of these are clearly out of date. For example, Fink doesn't even
> support Perl 5.8.5, and we don't support Perl 5.6.1 in 10.3 (at least
> there isn't a package for it that I can find). Most are missing 5.8.6,
> which is in unstable right now.
>
> --- Proposed solution ---
>
> I propose that we add a new percent expansion that looks like
> %{allperlversions} [I'm open to alternate suggestions] that expands to
> the list of all perl versions that Fink currently supports. This would
> let maintainers implicitly declare, "I expect that this module should
> work on any version of Perl". When new versions of Perl get added to
> Fink, no perlmods need to be updated. On the other hand, if a
> maintainer knows that a module only works for certain versions of Perl,
> that maintainer can set an explicit list just as we do now.
In an ideal world, people actually *test* packages, at least that they
compile, before committing them. Making new perl-variants
automatically spring into existence with the new perl is added removes
that step. Also, autogenerating the Type:perl subtype list does not
remove the burden of manually editing other parts of the .info where
these values are explicitly enumerated. That's because perl-variant
modules need to have the concept of exclusivity for the -man
splitoff. You'd have to somehow encode that into the Conflicts and
Replaces fields.
Conflicts: ${Ni}%{all-versions}-man
but somehow have that be expanded as a comma distribution operator.
That means each pkg has to know the full subtype list, something it
currently does not IIRC. That's gonna be quite a feat, since there's
no guarantee that all variants are contained in the same .info.
But actually, it's not "all versions of it" where "it" is the -man
splitoff: the multiple types are an attribute of the parent package,
and there is only one variant of the splitoff in each one. So you'd
need the splitoff to inherit the parent's subtype list--no big deal if
the parent already knows it.
Programming challenge aside, that means adding a new perlXXX pkg,
which autovivifies all these perlmod packages causes massive policy
breakage. Conflicts is hardcoded into the .deb, so the presence or
absense of different perlXXX packages will cause different users to
get different Conflicts for a given pkg-version at different times. A
given pkg-version *must* have a static replaces/conflicts field, so I
don't think there's any getting around having to manually enter the
perl subtypes into those fields. Having Type autogenerated but
Conflicts/Replaces means adding a new perlXXX-core will create a
complete collection of broken *-pmXXX packages until all their C/R are
manually adjusted.
vasi and I actually discussed this a few nights ago on #fink, and
buried the idea even further, so I may as well keep typing...
We really *don't* want Conflicts to give exclusivity among "all
currently-exising subtypes", but actually among all subtypes that have
*ever* existed for that pkg. We don't want to carry all obsolete
perlXXX-core indefinitely, but we also don't want to break upgrade
paths. Say I have perlXXX and foo-pmXXX (and -man) installed. Now a
new perlXXY is added and perlXXX is removed from the pkg repository; I
install perlXXY. Thanks to 'fink -b', I don't have to rebuild
everyhting myself: I just download the prebuilt foo-pmXXY, but if that
.deb came from a machine without perlXXX, its -man contains no
Conflicts for the one I have installed.
> The major open question is how %{allperlversions} gets populated. Is
> it hardcoded into PkgVersion.pm? Or does Fink scan the package list
> for perl5xx-core and system-perl5xx at runtime?
Hardcoded into fink core means one has to coordinate a new fink
release every time one wants to alter the set of perlXXX-core packages
we have. That's a bit too much Central Party package management for my
taste, and no reason to add yet another user and fink-release
headache. Runtime perlXXX-core determination is broken by policy and
function.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
