[Fink-devel] Perl variants -- problem and proposed solution
--- 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?
I assert that the former question is often answered by cargo cult:
maintainers just copy the choices made by other maintainers. I did a
quick test to see what choices people have made so far:
% cd /sw/fink/10.3/unstable/main/finkinfo/libs/perlmods
% egrep -rh 'Type: *perl *\(' . | sort -u
% egrep -rh 'Type: *perl' . | sort -u
Type: perl
Type: perl (5.6.0 5.6.1 5.8.0 5.8.1 5.8.4 5.8.5)
Type: perl (5.6.0 5.6.1 5.8.0 5.8.1 5.8.4)
Type: perl (5.6.0 5.8.0 5.8.1 5.8.4)
Type: perl (5.6.0 5.8.0 5.8.1)
Type: perl (5.6.0 5.8.1)
Type: perl (5.8.0 5.8.1 5.8.4)
Type: perl (5.8.0 5.8.1)
Type: perl (5.8.1 5.8.4 5.8.6)
Type: perl (5.8.1 5.8.4)
Type: perl (5.8.1)
Type: perl 5.6.0
Type: perl 5.8.0
Type: perl 5.8.1
Type: perl(5.6.0 5.6.1 5.8.0 5.8.1 5.8.4 5.8.5)
Type: perl(5.6.0 5.8.0 5.8.1 5.8.4)
Type: perl(5.6.0)
Type: perl(5.6.1 5.8.0 5.8.1 5.8.4)
Type: perl(5.8.1)
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.
If this is deemed to be good idea, I'd be happy to write the patch.
--- Switchover process ---
A nice feature of this solution is that no existing package will break.
Maintainers can switch over to using %{allperlversions} at their
leisure.
--- Open questions ---
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?
Chris
--
Chris Dolan, Software Developer, www.chrisdolan.net
Public key: http://www.chrisdolan.net/public.key
PGP.sig
Description: This is a digitally signed message part
[Fink-devel] ntop-1.1-22
-- Package manager version: 0.21.3 Distribution version: 0.7.1 Mac OS X version: 10.3.8 December 2001 Developer Tools gcc version: 3.3 make version: 3.79 Feedback Courtesy of FinkCommander ntop compiles, installs, and runs just fine in my environment. Thanks. --- 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=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl variants -- problem and proposed solution
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=6595alloc_id=14396op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl variants -- problem and proposed solution
Hi Chris. You've raised an important issue which I've been meaning to address. There are a couple of different philosophies about the choice of perl Types, and I think we need to discuss this and settle on a common policy. Let me break this into two questions: what Types should be used, and should there be a difference between stable and unstable. Historically, we've seen periods when substantial numbers of users had replaced their Apple-installed perl with a more recent version. Even Apple's website appeared to advocate doing this at one time. So we've tried to accomodate the needs of our users. (On the other hand, this causes lots of headaches, in particular, since we cannot always test things.) So one point of view says that we should include as many perl module variants as possible, to accomodate users who have replaced their system perl with a newer version. This is the point of view that leads to the inclusion of Type 5.8.5, even though we've never had a perl 5.8.5 package in fink and this variant cannot be tested with an ordinary installation of fink. Another point of view says that we should limit the Types to those that we actually support. I personally like the second point of view, but I'd be glad to hear discussion about this from adherents of the first point of view. By the way, at the moment, bootstrapping fink is only permitted with a short list of installed versions of perl. I have been tempted to also only permit updating fink with that same short list, but I'm wary of breaking things for some users, so I haven't done it. Turning to the second question, I firmly believe in maintaining a difference between the stable and unstable trees in regards to Types. Everything in the stable tree must build on a standard fink system, and will be built when a binary distribution is created. Thus, 5.8.5 can never go into stable. However, it's pretty easy to maintain a system in which the list of Types for a package is different in stable and unstable. For example, the list of -man packages that includes all variants in Conflicts and Replaces lines is perfectly appropriate, even if some of those variants don't exist in the stable tree. The only thing that has to be modified is the Type line. Future plans affecting this question: perl 5.8.6 will go into stable fairly soon, and I'm working on creating -pm586 variants of the stable -pm581 packages. Also, it is unlikely that we'll include any version of perl prior to 5.8.1 in our 10.4 distribution for fink. -- Dave --- 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=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl variants -- problem and proposed solution
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:
--- 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
--
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
[Fink-devel] Accessibility
I'm currently helping a local blind/deaf user get started with Fink. We're hoping to port the Linux BRLTTY braille translator to OSX, but this is new territory for me and this user is new to OSX, so we're learning things like the cmdline installer for DMGs, etc. Has anyone else explored this territory? Apple's accessibility page (http://www.apple.com/accessibility/) is interesting, but not very helpful. Chris -- 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
Re: [Fink-devel] Perl variants -- problem and proposed solution
Hi folks, While I agree with dmacks that we can't really automate this, I still think it's important to deal with. I think that if we support a perl version, we ideally want every variant to support that version. There are a few ways this could be accomplished: 1. Usually it's not considered especially polite to modify another maintainer's package. I think we should explicitly say that adding a new perl variant to another maintainer's package is ok, if it doesn't require any non-trivial changes. 2. We may want to have a policy that all perl packages with variants should be tested with all supported perl versions, assuming dependencies allow it. Or, we could require this only on entry to stable. 3. If there are any people who particularly care about a certain perl version, we could have a perl-testing group of some sort. Or we could just have things ad-hoc like they are now :-) . Any comments? Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/languages gcc4.info,1.2,1.3
Jeff Whitaker committed: Index: gcc4.info === RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/languages/gcc4.info,v +++ gcc4.info 13 Feb 2005 03:20:41 - 1.3 +ConfigureParams: --prefix=%p/lib/gcc4 [...] --host=%m-apple-darwin Excellent, Jeff! 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=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: Perl variants -- problem and proposed solution
Dave Vasilevsky wrote: Hi folks, While I agree with dmacks that we can't really automate this, I still think it's important to deal with. I think that if we support a perl version, we ideally want every variant to support that version. There are a few ways this could be accomplished: 1. Usually it's not considered especially polite to modify another maintainer's package. I think we should explicitly say that adding a new perl variant to another maintainer's package is ok, if it doesn't require any non-trivial changes. I'm ok with this, as long as they tested the package under the new version. 2. We may want to have a policy that all perl packages with variants should be tested with all supported perl versions, assuming dependencies allow it. Or, we could require this only on entry to stable. I maintain many different versions of Perl (5.6.1, 5.6.2, 5.8.0, 5.8.2, 5.8.3, 5.8.4, 5.8.5 and 5.8.6) for my own open-source project and I do find on a regular basis that a new version of Perl will break at least one Perl module out of the 172 Perl modules that I install. So I agree that all modules should be tested and if a module breaks, a report goes to rt.cpan.org. Regards, Blair -- Blair Zajac [EMAIL PROTECTED] Plots of your system's performance - http://www.orcaware.com/orca/ --- 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=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
