[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=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[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=6595&alloc_id=14396&op=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 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] 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
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
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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[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=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[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