On May 4, 2012, at 10:56 PM, Alexander Hansen wrote:
> On 5/4/2012 8:54 PM, Jack Howarth wrote:
>> My biggest concern with the 10.8 support is the situation with the perlmod
>> packages.
>> Specifically whether we could adjust fink to automatically handle the newer
>> perl in each OS
>> release without requiring every single *-pm.info file to be adjusted
>> initially. Daniel
>> Macks suggested adding a system perl variant to the Type list for the perl
>> versions in
>> the *-pm.info files. I am unclear how this would possibly work across OS
>> releases though
>> since it the system-perl variant would install into a different versioned
>> subdirectory
>> for 10.7 (5.12.3) than for 10.8 (5.12.4) thus requiring all of the installed
>> system-perl
>> variants to be rebuilt after upgrading the OS.
>> The approach I was hoping we could implement would be a fall-thru where if
>> the user
>> executed...
>>
>> fink install foobar-pm5124
>>
>> while bootstrapped under 10.8 when 5.12.4 wasn't yet added to the Type perl
>> and
>> (%type_pkg[perl] = 5124) 10.8 wasn't added to the Distribution field of
>> foobar-pm.info
>> that fink would automatically check if system perl was of the desired version
>> for the package and then effectively append that perl version to the Type
>> perl
>> so that %type_pkg[perl], type_raw[perl], type_num[perl] could work normally
>> in
>> the existing *-pm.info files. If this could be made to work in the existing
>> fink
>> framework, we might only have to adjust instances like..
>>
>> if [ "%type_pkg[perl]" = "5100" ]&& [ "%m" != "powerpc" ] ; then
>> sed -e 's|/usr/bin/env|/usr/bin/arch -%m|g' -e 's|@PREFIX@|%p|g' -e
>> 's|@PERL_RAW@|%type_raw[perl]|g'< %{PatchFile} | patch -p1
>> elif [ "%type_pkg[perl]" = "5123" ] || [ "%type_pkg[perl]" = "5124" ] ; then
>> sed -e 's|@PREFIX@|%p|g' -e 's|env perl@PERL_RAW@|env perl5.12|g' -e
>> 's|@PERL_RAW@|%type_raw[perl]|g'< %{PatchFile} | patch -p1
>> else
>> sed -e 's|@PREFIX@|%p|g' -e 's|@PERL_RAW@|%type_raw[perl]|g'< %{PatchFile}
>> | patch -p1
>> fi
>>
>> to be something more portable like...
>>
>> elif [ "%type_pkg[perl]" -ge "5123" ] ; then
>>
>> Note that I am not suggesting that maintainers would have to abandon adding
>> the explicit perl versions
>> to the Type perl entry but rather than we adjust things so that the existing
>> perlmods info set will be
>> usable in general without requiring explicitly adding the new perl version
>> on each OS release.
>> Jack
>>
>>
> Actually, _I_ was the one who suggested the "system" thing, and Daniel
> pointed out that it would only be workable under the circumstance that
> 10.8 had its own collection of .info files. If they share a tree, then
> the situation is indeed what you mentioned, and the packages would need
> to be rebuilt.
>
> What you're effectively asking about here is having fink automatically
> generate the -pm5XYZ variants for all Type: perl packages, where XYZ are
> set for a given Distribution. Ideally, it would also need an override
> mechanism, for the case where a perlmod can't be built on a newer Perl
> (probably not an issue for the 0.0.1 jump we're talking here, but we
> might as well try to be future-proof).
>
> I'll propose an alternate option here. Historically, what we did was
>
> 1) Create a Fink perl package of the same version as that in the
> upcoming OS X version.
> 2) Create a Fink perl package of the same version as that in the
> currently released OS X version.
> 3) Populate the perlmods for the new Perl version.
>
> So how about a Fink perl5124 package for Lion and a perl5123 package for
> Mountain Lion? This avoids the necessity of Distribution tags altogether
> for perlmods in the 10.7 tree (at least for now).
>
> It's true that we've got a lot of cruft related to all of the historical
> architecture and distribution restrictions, and what I would also
> propose is that the maintainers (or -core) go through the 10.7 tree and
> excise these no-ops. I'm aware that this makes it a bit harder for the
> maintainers to keep the 10.7 and 10.4 .info files in sync, but this is
> by no means insurmountable--one can use a graphical merge editor, for
> instance. If we got rid of that cruft, we wouldn't even need stuff like
>
> if [ "%type_pkg[perl]" -ge "5123" ] ; then
>
> because we _know_ that there is no earlier system or Fink Perl for Lion
> and later.
>
> At that point, we can pretty much just use a quick one-liner to add the
> 5.12.4 type in for many of the perlmods.
>
> On the other hand, this will require a lot of editing of files.
I have a couple of points to make.
1) There was a problem with this "build our own fink" strategy with 10.6,
because Apple was shipping a "fat" perl whereas we wanted fink to run in either
32bit or 64bit mode, and the fink-built perl was not functioning well as a
drop-in replacement. However, for 10.7 -> 10.8 this should not longer be an
issue. Hopefully we can build 5.12.4 for 10.7 without any difficulty.
2) Another problem we had once upon a time is that Apple changed the perl
version between early seeds and release. Jack, I gather that you are talking
to some Apple engineers these days; if you could get them to hint at the plans
in this regard, that would be great.
3) The big issue with any automated system for upgrading perl packages to a new
pm-XXX is that most perlmod packages aren't being actively maintained, and
while an older version of the perlmod will continue to work perfectly well with
an older perl, often the perlmod itself needed to be updated (and was,
upstream) to work with current perl. Thus, we need to do more than just add
5.12.4 to the Type; we need to test whether it builds, and possibly update the
version to the latest upstream one.
4) A lot of the cruft in -pm.info files was generated during previous upgrades
fairly automatically. It was pretty easy to script the addition of a Type and
the appropriate conditional Distribution field. People on the core team could
do this locally and then commit each file only after testing. I would advocate
adding to the cruft rather than cleaning up the cruft, at least for packages
that have a Maintainer, to address the ease-of-keeping-trees-in-sync issue. If
there is no Maintainer of record, though, we might as well ignore 10.4 and
clean up the 10.7 one.
-- Dave
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
