On Jul 22, 2014, at 5:59 PM, Mojca Miklavec <mo...@macports.org> wrote:
>
> On Tue, Jul 22, 2014 at 7:37 PM, Daniel J. Luke wrote:
>> On Jul 22, 2014, at 11:51 AM, Mojca Miklavec wrote:
>>> On Jul 19, 2014 1:15 AM, "David Evans" wrote:
>>>> On 7/18/14 3:47 PM, Mojca Miklavec wrote:
>>>> Well, I'm sorry but I don't really see the need for these experiments.
>>>
>>> At the moment it is very inconvenient to upgrade perl from 5.x.y to
>>> 5.x.(y+1). A bunch of "random" ports become broken "just because" (because
>>> they link against perl and location of a fully compatible libperl.dylib
>>> changes for no good reason).
>>
>> maybe we should symlink libperl.dylib to somewhere stable?
>
> How exactly? (That's not a rhetorical question.)
add a symlink in post-destroot? add it to the current perl5 port?
I haven't looked at how perl modules find libperl.dylib, though - so it might
require something in the perl5 portgroup to get them to use the symlink
location. (And if we had a way to force rebuilds or revbump all perl modules
when we upgrade perl, it wouldn't really be necessary).
>> we should probably enhance `port test` to be more useful. With the perl
>> modules (at least), they usually have test suites that we should be able to
>> run to verify we're not breaking things - so changes to MacPorts perl could
>> get some tests 'for free'
>
> That needs more thinking. It would be certainly useful to have more
> tests, but I'm not sure what exactly.
basically every cpan module has tests already, so being able to have macports
do builds (and include running the tests) would make it easier to see if any
changes break a large number of perl module ports or not (and may enable us to
try a couple of ideas without fear of breaking a large number of installs).
Additionally, it could point us to modules that currently build fine but don't
actually work.
>>> - I'm willing to test a bunch of ports, but once we add p5.20 it will be
>>> very time consuming and a lot of mess to change things in *all* python
>>> modules.
>>
>> s/python/perl/ ?
>
> Yes, I'm sorry. (Even though python is facing similar "problems" as
> perl with zillions of versions, only in a waaaay less problematic
> way.)
there are fewer pythons to worry about, if that's what you mean. perl
compatibility between versions is better, though, so I'm not sure 'less
problematic' is correct. [Of course, the proliferation of perl5.x ports is
entirely our fault].
>> we should really just fix our multiple-perl problems by pushing one perl5
>> (the latest perl5 release from upstream) and shipping one set of p5-modules
>> (that build against the latest upstream perl5 release)
>>
>>> - I'm almost sure that hardly anyone will be willing to do any considerable
>>> amount of testing, so it will boil down to max 5 people testing at the end
>>> anyway and most bugs would surface later.
>>
>> which has actually been the case for most of MacPorts for most of its life
>> anyway, so it's not really a problem ;-) [or at least, not a new one]
>>
>>> - There are plans to change the way how Perl and Perl modules are written
>>> and installed, but we should continue updating ports until then. However
>>> spending an enormous amount of time changing and fixing a large number of
>>> ports would be almost a wasted effort (given that most of the work done now
>>> will be thrown away anyway).
>>>> But I do point out that perl 5.20 is the current stable release
>>> And we didn't even port any noticable amount of ports to 5.18, let alone
>>> make 5.18 the default perl version.
>>
>> So here's my short proposal:
>>
>> 1. switch the perl5 port to actually install perl5.20.x
>> 2. deprecate and remove the other perl5.x ports
>> 3. change the perl5 portgroup to just build/install p5 ports that work with
>> whatever we install as perl5 (currently 5.20.x)
>> 4. Update other ports to depend on the p5- module(s) and the perl5 port
>> 5. Make some way to (easily) force rebuilds of all p5 ports when there's a
>> new release of perl5.x.y (probably on both new .x.0 and .x.y releases)
>> * one thing I thought might work would be to [ab]use epoch by setting it to
>> the YYYYMMDD of the perl5 release in the perl5 portgroup (so individual
>> ports can still update it to a newer epoch if needed, and we can keep
>> bumping it for every perl5 version). I haven't though about it too much or
>> tested it yet, though.
>>
>> longer term:
>> 6. better CPAN integration (get module list from CPAN, build using something
>> like cpanm, install our own cpanm that installs the appropriate port, etc.).
>> There are too many modules that update too frequently for the current level
>> of contributors to provide well-tested and updated ports of the individual
>> CPAN packages.
>
> I think that we should maintain a database of all perl modules in a
> single file and semi-auto-update that file from CPAN on regular basis.
> Only non-standard settings could then be replaced in individual
> Portfiles and for most ports we wouldn't even need a Portfile.
>
> But both what you said and what I wrote requires some work and
> testing. And cannot be the answer to "we urgently need to allow 5.20".
that's why it was under 'longer term' ;-)
> I'm currently committing a bunch of changes in perl modules that I
> have "on stack". Once I'm over the list, I'll look into Perl 5.20 to
> see if I can fix the problem with a trivial change.
thoughts on 1-5?
Our perl situation really doesn't need to be as complicated as it is...
--
Daniel J. Luke
+========================================================+
| *---------------- dl...@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
