Good points. I withdraw the proposal.
Daniel, do you recommend that non-variant Perl modules must also be tested against all Fink-supported versions of Perl?
Chris
On Feb 14, 2005, at 9:05 AM, Daniel Macks wrote:
On Sat, Feb 12, 2005 at 09:34:59PM -0600, Chris Dolan wrote:[maintainers list all kinds of combinations]--- 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?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
-- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
PGP.sig
Description: This is a digitally signed message part
