Re: ticket 41037: libetpan upgrade

[Joshua Root]

On 2014-8-13 07:14 , Frank Schima wrote:
> 
> On Jul 6, 2014, at 8:28 PM, Perry E. Metzger  wrote:
> 
>> Howdy;
>>
>> I've been waiting for the maintainer to respond to the ticket I
>> filed eight months ago about the macports libetpan being very, very
>> obsolete. Original is here:
>>
>> https://trac.macports.org/ticket/41037
>>
>> Thoughts on what to do next?
> 
> Committed in r123694 with maintainer timeout.

I notice the patch was never updated in response to the points that Ryan
raised. Did it turn out that no changes were necessary? The "Unsure if
this is needed" comment should be removed if so.

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: ticket 41037: libetpan upgrade

[Perry E. Metzger]

On Tue, 12 Aug 2014 15:14:11 -0600 Frank Schima 
wrote:
> 
> On Jul 6, 2014, at 8:28 PM, Perry E. Metzger 
> wrote:
> 
> > Howdy;
> > 
> > I've been waiting for the maintainer to respond to the ticket I
> > filed eight months ago about the macports libetpan being very,
> > very obsolete. Original is here:
> > 
> > https://trac.macports.org/ticket/41037
> > 
> > Thoughts on what to do next?
> 
> Committed in r123694 with maintainer timeout.

Hi!

It has been so long in the meantime that libetpan has progressed to
version 1.5 -- could the port be updated as well? That would likely
only require a number bump, fixing the hashes, and a quick check that
the result still works.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 5:25 PM, Dan Ports  wrote:
> 
> On Tue, Aug 12, 2014 at 08:19:27AM -0700, David Evans wrote:
>> As Daniel has said, no point in changing things that are going to go away so
>> we need to get a consensus on where we want to go with this.  My input here
>> would be this:
>> 
>> *  make the necessary changes to perl5.18 to work as perl5.20 does
>> *  leave perl5.16 and lower alone for now
>> *  update ports to support p5.18 & 5.20 unless there is strong sentiment
>> to go to 5.20 ASAP.
>>   not much difference in adding one or two new branches
>> *  then decided which branches to remove, go to single perl (which has
>> other consequences), etc.
> 
> This makes sense to me. I don't know enough about perl to comment
> usefully on the subrelease path issue, so I'll leave that to people who
> actually know what they're talking about.

it probably doesn't hurt anything (and does maybe make things slightly easier). 
I would prefer that we patch the upstream perl as little as possible, though.

[we could continue working around the issue by just revbumping all the p5 ports 
when we upgrade our one true perl5 and possibly eventually enhance macports so 
that a port can indicate that its dependencies need to be rebuilt]

> I think it is worth adding support for p5.18 and 5.20 to the current
> p5 ports since that doesn't seem terribly onerous -- especially if
> Mojca has already written a patch :). And it'll give us a chance to see
> if any of the existing perl modules have trouble building for
> 5.18/5.20.
> 
> Longer-term, we need to decide whether to go to a single perl.
> Personally, I'm in favor of this. But it's clearly going to involve a
> lot of work (even if it'll save us more in the long run) so we
> shouldn't let that stop us from doing this now.

I don't think it's really any more work than what is going on now. The hardest 
thing will be trying to make the transition work well for people (and maybe we 
just can't make it nice? - changes to default perl5 are already not picked up 
by installs, so people have to do manual work to get their install using a 
newer perl5).

A reasonable interim goal state would be:
1. perl5 port installs the current perl5 (which is 5.20.0 right now)
2. p5 ports install like they used to (perl5 portgroup doesn't make versioned 
p5.xx modules anymore)
3. ports depend on p5-xxx or the perl5 port

To me, it makes sense to figure out a plan on how we get to that state, and not 
spend a lot of time making keeping the currently broken situation mostly 
working.

As we often have things that don't quite work, I'm not opposed to having a lot 
of things broken (on a branch, probably) while this is being worked on/figured 
out. It would probably be helpful to write up an automated procedure to run 
through all of the testsuites for the perl module ports.

Once we've simplified things (one perl, one set of perl module ports) - then we 
can more sanely try to tackle the other things we need to do in order to make 
MacPorts perl more useful.

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Dan Ports]

On Tue, Aug 12, 2014 at 08:19:27AM -0700, David Evans wrote:
> As Daniel has said, no point in changing things that are going to go away so
> we need to get a consensus on where we want to go with this.  My input here
> would be this:
> 
> *  make the necessary changes to perl5.18 to work as perl5.20 does
> *  leave perl5.16 and lower alone for now
> *  update ports to support p5.18 & 5.20 unless there is strong sentiment
> to go to 5.20 ASAP.
>not much difference in adding one or two new branches
> *  then decided which branches to remove, go to single perl (which has
> other consequences), etc.

This makes sense to me. I don't know enough about perl to comment
usefully on the subrelease path issue, so I'll leave that to people who
actually know what they're talking about.

I think it is worth adding support for p5.18 and 5.20 to the current
p5 ports since that doesn't seem terribly onerous -- especially if
Mojca has already written a patch :). And it'll give us a chance to see
if any of the existing perl modules have trouble building for
5.18/5.20.

Longer-term, we need to decide whether to go to a single perl.
Personally, I'm in favor of this. But it's clearly going to involve a
lot of work (even if it'll save us more in the long run) so we
shouldn't let that stop us from doing this now.

Dan

-- 
Dan R. K. PortsUW CSEhttp://drkp.net/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: ticket 41037: libetpan upgrade

[Frank Schima]

On Jul 6, 2014, at 8:28 PM, Perry E. Metzger  wrote:

> Howdy;
> 
> I've been waiting for the maintainer to respond to the ticket I
> filed eight months ago about the macports libetpan being very, very
> obsolete. Original is here:
> 
> https://trac.macports.org/ticket/41037
> 
> Thoughts on what to do next?

Committed in r123694 with maintainer timeout.


Cheers!
Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

Another thing that I noticed: running installer in trace mode reveals
many missing basic dependencies in basically all modules.

Typical example:

Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/Liblist.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/Liblist/Kid.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MM.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MM_Any.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MM_Darwin.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MM_Unix.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MY.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MakeMaker.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/MakeMaker/Config.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/ExtUtils/Manifest.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/File/Temp.pm
Warning: An activity was attempted outside sandbox:
/opt/local/lib/perl5/vendor_perl/5.18/darwin-thread-multi-2level/Data/Dumper.pm

Yet this never seems to be a problem on the buildbot.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 6:43 PM, David Evans wrote:
> On 8/12/14 9:30 AM, Frank Schima wrote:
>>
>> I see no reason to change perl 5.16 or lower because they are already 
>> working. Let’s just look forward to 5.18 and 5.20. Even if 5.18 is a lame 
>> duck already.
>>
>> For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx 
>> and possibly a few others that work fine with p5.16.
>
> Sounds good to me.  If we can agree on this, then maybe we can move on and
> make some progress.  Otherwise, 5.22 may be out before we make a
> decision

After this discussion I also have a feeling that in the spirit of
"don't fix something that isn't broken" it might be better to leave
5.16 (and lower) intact. The change isn't all that well tested after
all. If I only change 5.18 and if we find some problems, we can easily
fix those without hard pressure. If we break something in 5.16, we'll
probably break just about everyone's installation and will need to
rush to fix any problems that might arise.

Since 5.16 isn't going to see a new release and given that the change
doesn't really bring any new functionality to the table (just
potentially causes unexpected problems), it might be better to leave
it as is.


So basically I'm ready to commit

https://trac.macports.org/attachment/ticket/43480/perl5.18-remove-subrelease.2.2.diff
Testing is welcome, but I wouldn't like to wait too long before
committing, so that we could continue working on the rest of the
tasks. After all everyone will still have a working 5.16 version
installed as the worst case scenario ;)

I tried installing all ports that I modified. I didn't do extensive
checks on missing dependencies. With most of the ports I didn't run
the tests (if there was an automated way to do it, I probably would
have done it). I had problems upgrading p5-inline, p5-perlmagick and
p5-const-fast, so I just revbumbed them and kept them at the old
versions. Other ports that failed are listed in the ticket (there
weren't many).

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Frank Schima]

On Aug 12, 2014, at 10:30 AM, Frank Schima  wrote:

> For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx 
> and possibly a few others that work fine with p5.16. 

I meant p5-pdl here. 


-Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 9:30 AM, Frank Schima wrote:
> On Aug 12, 2014, at 10:03 AM, Mojca Miklavec  wrote:
>
>> On Tue, Aug 12, 2014 at 5:23 PM, Ryan Schmidt wrote:
 On Aug 12, 2014, at 10:20 AM, David Evans wrote:
 On 8/12/14 8:06 AM, Ryan Schmidt wrote:
> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec wrote:
>> Now about 5.8-5.16: my idea was to initially set the INC path for
>> those versions in such a way that it would include
>> "5.16.3/darwin-thread-multi-2level 5.16.3
>> 5.16.1/darwin-thread-multi-2level 5.16.1
>> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
>> /5.16/ without the subrelease. That means that
>> there would initially be no urgent need to revbump all the > 1000
>> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
>> would make sure to revbump all p5.18-foo ports.)
>>
>> But I'm unable to figure out how to patch Perl to do that. The INC
>> path additions seem to be ignored.
> Why handle <= 5.16 differently than >= 5.18?
>> Because for >= 5.18 everything will work out-of-the-box once I apply a
>> huge patch (cca 300 revbumps or updates). It will work automatically
>> on ports where we add 5.18/5.20 later.
>>
>> For <= 5.16 see below.
>>
 Because we want them to go away? Or is the effort to do them all
 relatively trivial?
>>> My assumption was that since a patch is already in place for perl5.20 and 
>>> perl5.18 it could be backported to earlier versions with minimal effort,
>> We can either clean up the INC path entirely (the same way as it's
>> done in 5.18 and 5.20), but then need to also revbump the remaining >
>> 700 modules (which needs to be done at some point anyway, if nothing
>> else because we'll have to add 5.18 and 5.20 and also because half of
>> those modules needs an update). But then this would have to be done
>> "at once".
>>
>> My idea of a relatively trivial fix was to change the path where
>> perl5.16 installs files, so that perl would keep looking at the old
>> locations. It turned out that the patch wasn't exactly as trivial as I
>> thought it would be. And I'm not yet sure why. But I bet that the
>> patch isn't that complicated either. It might be one-liner once we
>> figure out what and where to fix. See
>>https://trac.macports.org/ticket/43480#comment:10
>>
>> Anyone willing to help me out is invited to check what exactly is
>> wrong with the patch I proposed.
>>
>>
>> So it's probably still easy to do, but not as trivial as I hoped it to be.
>>
>> Other reasons for handling perl5.16 differently include:
>>
>> - most likely there will be no perl 5.16.4 (and most certainly no perl
>> 5.14.5, 5.12.6, ...), so we probably don't need to care about
>> locations of modules and libraries changing in the future
>>
>> - once we complete support for 5.18 and 5.20, implement something like
>> "5.10-foo replaced_by 5.20-foo" and switch dependencies from p5.12-foo
>> to p5.20-foo, we could theoretically drop support for older perls; we
>> keep 5.12 around just because lots of ports depend on it (but don't
>> really need to depend on it)
>>
>> - versions <= 5.16 are no longer supported upstream
>>
>> - my patch to drop the subrelease number is not really supported
>> upstream and has not been tested too extensively; it might be that
>> some obscure module actually depends on the fact that the module path
>> should contain three numbers; so if p5.16-foo would keep working and
>> p5.18-foo not, you could point your fingers at that patch ;)
>>
>>> and that since Mojca plans a revbump of all perl modules anyway, before 
>>> that mass revbumping would be the ideal time to do that.
>> Yes. The ideal time would be now. That is: if we want to do it at all.
>> But patching <= 5.16 apparently means either adjusting the patch a bit
>> or revbumping also the other > 700 ports at the same time (which could
>> be automated).
> I see no reason to change perl 5.16 or lower because they are already 
> working. Let’s just look forward to 5.18 and 5.20. Even if 5.18 is a lame 
> duck already. 
>
> For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx 
> and possibly a few others that work fine with p5.16. 
>
>
> Cheers!
> Frank
>

Sounds good to me.  If we can agree on this, then maybe we can move on and
make some progress.  Otherwise, 5.22 may be out before we make a
decision 

Dave

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Frank Schima]

On Aug 12, 2014, at 8:45 AM, Mojca Miklavec  wrote:

> On Tue, Aug 12, 2014 at 4:30 PM, Daniel J. Luke wrote:
>> On Aug 12, 2014, at 10:15 AM, Mojca Miklavec wrote:
>>> 
>>> Other than that I can definitely create a new branch to simplify
>>> testing and add the same patch to all perl versions. But the request
>>> to wait with updates a bit (unless it's really really really needed)
>>> still stands.
>> 
>> you could create a branch with just the most recent upstream perl (currently 
>> perl5.20.0) and interested parties could test that maybe?
>> 
>> probably simpler than trying to do stuff for each of the perl5 versions we 
>> currently have (and hopefully gets us to 'one perl' more quickly?)
> 
> I would say "let's solve one problem at a time". At this time I
> believe it will be least painful and most efficient to simply add 5.18
> and 5.20 to all modules. But before this is added I would *really*
> like to get rid of the subrelease number(s).
> 
> Then we can make Perl 5.20 default (just to confuse everyone working
> on https://trac.macports.org/ticket/44405) etc.

For the record, I have no problem with superseding this ticket with a new one 
to move to perl 5.20 when we get all of the p5.20 ports working. 

> Btw: some modules like p5-wx are broken in Perl 5.20. Having 5.18
> available may help in such situations.

p5-pdl is broken on both p5.18 and p5.20. Hopefully we can just get everything 
working on p5.20 to move forward. 

Here are the related tickets that, as far as I know, are holding up the move to 
p5.20. 

 - #44416 - p5-wx 
 - #44439 - p5-pdl 


Cheers!
Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Clemens Lang]

> Is there data coming in through mpstats that could help with this
> decision?  What is the distribution of perl installs by version?

No helpful data from mpstats at the moment. Don't bother checking.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Craig Treleaven]

At 8:32 AM -0700 8/12/14, David Evans wrote:

On 8/12/14 8:23 AM, Ryan Schmidt wrote:

 On Aug 12, 2014, at 10:20 AM, David Evans  wrote:

 On 8/12/14 8:06 AM, Ryan Schmidt wrote:

 On Aug 12, 2014, at 9:56 AM, Mojca Miklavec  wrote:

 Now about 5.8-5.16: my idea was to initially set the INC path for
 those versions in such a way that it would include
 "5.16.3/darwin-thread-multi-2level 5.16.3
 5.16.1/darwin-thread-multi-2level 5.16.1
 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
 /5.16/ without the subrelease. That means that
 there would initially be no urgent need to revbump all the > 1000
 ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
 would make sure to revbump all p5.18-foo ports.)

 But I'm unable to figure out how to patch Perl to do that. The INC
 path additions seem to be ignored.

 Why handle <= 5.16 differently than >= 5.18?



 Because we want them to go away? Or is the effort to do them all
 relatively trivial?


 My assumption was that since a patch is already in place for 
perl5.20 and perl5.18 it could be backported to earlier versions 
with minimal effort, and that since Mojca plans a revbump of all 
perl modules anyway, before that mass revbumping would be the ideal 
time to do that.




Agreed.  If the effort is trivial it doesn't make much difference.  But
if we want to drop some branches then why bother with them?  For
instance, IMO we could drop 5.8 and 5.10.  And 5.12 as soon as the
remaining ports that depend on it are fixed.  Then 5.14.  I don't think
we can get rid of 5.16 until either 5.18 5.20 or both have the same
coverage and we're ready to switch to a new default.

But again this depends on where we are going?

Ryan, as a member of the executive branch ;-), do you have a method to
come up with a final decision on the direction for perl?  I think it's
all been discussed more than enough.


Is there data coming in through mpstats that could help with this 
decision?  What is the distribution of perl installs by version?


Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Frank Schima]

On Aug 12, 2014, at 10:03 AM, Mojca Miklavec  wrote:

> On Tue, Aug 12, 2014 at 5:23 PM, Ryan Schmidt wrote:
>>> On Aug 12, 2014, at 10:20 AM, David Evans wrote:
>>> On 8/12/14 8:06 AM, Ryan Schmidt wrote:
 On Aug 12, 2014, at 9:56 AM, Mojca Miklavec wrote:
> Now about 5.8-5.16: my idea was to initially set the INC path for
> those versions in such a way that it would include
> "5.16.3/darwin-thread-multi-2level 5.16.3
> 5.16.1/darwin-thread-multi-2level 5.16.1
> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
> /5.16/ without the subrelease. That means that
> there would initially be no urgent need to revbump all the > 1000
> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
> would make sure to revbump all p5.18-foo ports.)
> 
> But I'm unable to figure out how to patch Perl to do that. The INC
> path additions seem to be ignored.
 Why handle <= 5.16 differently than >= 5.18?
> 
> Because for >= 5.18 everything will work out-of-the-box once I apply a
> huge patch (cca 300 revbumps or updates). It will work automatically
> on ports where we add 5.18/5.20 later.
> 
> For <= 5.16 see below.
> 
>>> Because we want them to go away? Or is the effort to do them all
>>> relatively trivial?
>> 
>> My assumption was that since a patch is already in place for perl5.20 and 
>> perl5.18 it could be backported to earlier versions with minimal effort,
> 
> We can either clean up the INC path entirely (the same way as it's
> done in 5.18 and 5.20), but then need to also revbump the remaining >
> 700 modules (which needs to be done at some point anyway, if nothing
> else because we'll have to add 5.18 and 5.20 and also because half of
> those modules needs an update). But then this would have to be done
> "at once".
> 
> My idea of a relatively trivial fix was to change the path where
> perl5.16 installs files, so that perl would keep looking at the old
> locations. It turned out that the patch wasn't exactly as trivial as I
> thought it would be. And I'm not yet sure why. But I bet that the
> patch isn't that complicated either. It might be one-liner once we
> figure out what and where to fix. See
>https://trac.macports.org/ticket/43480#comment:10
> 
> Anyone willing to help me out is invited to check what exactly is
> wrong with the patch I proposed.
> 
> 
> So it's probably still easy to do, but not as trivial as I hoped it to be.
> 
> Other reasons for handling perl5.16 differently include:
> 
> - most likely there will be no perl 5.16.4 (and most certainly no perl
> 5.14.5, 5.12.6, ...), so we probably don't need to care about
> locations of modules and libraries changing in the future
> 
> - once we complete support for 5.18 and 5.20, implement something like
> "5.10-foo replaced_by 5.20-foo" and switch dependencies from p5.12-foo
> to p5.20-foo, we could theoretically drop support for older perls; we
> keep 5.12 around just because lots of ports depend on it (but don't
> really need to depend on it)
> 
> - versions <= 5.16 are no longer supported upstream
> 
> - my patch to drop the subrelease number is not really supported
> upstream and has not been tested too extensively; it might be that
> some obscure module actually depends on the fact that the module path
> should contain three numbers; so if p5.16-foo would keep working and
> p5.18-foo not, you could point your fingers at that patch ;)
> 
>> and that since Mojca plans a revbump of all perl modules anyway, before that 
>> mass revbumping would be the ideal time to do that.
> 
> Yes. The ideal time would be now. That is: if we want to do it at all.
> But patching <= 5.16 apparently means either adjusting the patch a bit
> or revbumping also the other > 700 ports at the same time (which could
> be automated).

I see no reason to change perl 5.16 or lower because they are already working. 
Let’s just look forward to 5.18 and 5.20. Even if 5.18 is a lame duck already. 

For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx and 
possibly a few others that work fine with p5.16. 


Cheers!
Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 5:23 PM, Ryan Schmidt wrote:
>> On Aug 12, 2014, at 10:20 AM, David Evans wrote:
>> On 8/12/14 8:06 AM, Ryan Schmidt wrote:
>>> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec wrote:
 Now about 5.8-5.16: my idea was to initially set the INC path for
 those versions in such a way that it would include
 "5.16.3/darwin-thread-multi-2level 5.16.3
 5.16.1/darwin-thread-multi-2level 5.16.1
 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
 /5.16/ without the subrelease. That means that
 there would initially be no urgent need to revbump all the > 1000
 ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
 would make sure to revbump all p5.18-foo ports.)

 But I'm unable to figure out how to patch Perl to do that. The INC
 path additions seem to be ignored.
>>> Why handle <= 5.16 differently than >= 5.18?

Because for >= 5.18 everything will work out-of-the-box once I apply a
huge patch (cca 300 revbumps or updates). It will work automatically
on ports where we add 5.18/5.20 later.

For <= 5.16 see below.

>> Because we want them to go away? Or is the effort to do them all
>> relatively trivial?
>
> My assumption was that since a patch is already in place for perl5.20 and 
> perl5.18 it could be backported to earlier versions with minimal effort,

We can either clean up the INC path entirely (the same way as it's
done in 5.18 and 5.20), but then need to also revbump the remaining >
700 modules (which needs to be done at some point anyway, if nothing
else because we'll have to add 5.18 and 5.20 and also because half of
those modules needs an update). But then this would have to be done
"at once".

My idea of a relatively trivial fix was to change the path where
perl5.16 installs files, so that perl would keep looking at the old
locations. It turned out that the patch wasn't exactly as trivial as I
thought it would be. And I'm not yet sure why. But I bet that the
patch isn't that complicated either. It might be one-liner once we
figure out what and where to fix. See
https://trac.macports.org/ticket/43480#comment:10

Anyone willing to help me out is invited to check what exactly is
wrong with the patch I proposed.


So it's probably still easy to do, but not as trivial as I hoped it to be.

Other reasons for handling perl5.16 differently include:

- most likely there will be no perl 5.16.4 (and most certainly no perl
5.14.5, 5.12.6, ...), so we probably don't need to care about
locations of modules and libraries changing in the future

- once we complete support for 5.18 and 5.20, implement something like
"5.10-foo replaced_by 5.20-foo" and switch dependencies from p5.12-foo
to p5.20-foo, we could theoretically drop support for older perls; we
keep 5.12 around just because lots of ports depend on it (but don't
really need to depend on it)

- versions <= 5.16 are no longer supported upstream

- my patch to drop the subrelease number is not really supported
upstream and has not been tested too extensively; it might be that
some obscure module actually depends on the fact that the module path
should contain three numbers; so if p5.16-foo would keep working and
p5.18-foo not, you could point your fingers at that patch ;)

> and that since Mojca plans a revbump of all perl modules anyway, before that 
> mass revbumping would be the ideal time to do that.

Yes. The ideal time would be now. That is: if we want to do it at all.
But patching <= 5.16 apparently means either adjusting the patch a bit
or revbumping also the other > 700 ports at the same time (which could
be automated).

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 8:23 AM, Ryan Schmidt wrote:
>> On Aug 12, 2014, at 10:20 AM, David Evans  wrote:
>>
>> On 8/12/14 8:06 AM, Ryan Schmidt wrote:
>>> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec  wrote:
 Now about 5.8-5.16: my idea was to initially set the INC path for
 those versions in such a way that it would include
 "5.16.3/darwin-thread-multi-2level 5.16.3
 5.16.1/darwin-thread-multi-2level 5.16.1
 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
 /5.16/ without the subrelease. That means that
 there would initially be no urgent need to revbump all the > 1000
 ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
 would make sure to revbump all p5.18-foo ports.)

 But I'm unable to figure out how to patch Perl to do that. The INC
 path additions seem to be ignored.
>>> Why handle <= 5.16 differently than >= 5.18?
>>>
>>>
>> Because we want them to go away? Or is the effort to do them all
>> relatively trivial?
>>
>>
> My assumption was that since a patch is already in place for perl5.20 and 
> perl5.18 it could be backported to earlier versions with minimal effort, and 
> that since Mojca plans a revbump of all perl modules anyway, before that mass 
> revbumping would be the ideal time to do that.
>
>
Agreed.  If the effort is trivial it doesn't make much difference.  But
if we want to drop some branches then why bother with them?  For
instance, IMO we could drop 5.8 and 5.10.  And 5.12 as soon as the
remaining ports that depend on it are fixed.  Then 5.14.  I don't think
we can get rid of 5.16 until either 5.18 5.20 or both have the same
coverage and we're ready to switch to a new default.

But again this depends on where we are going? 

Ryan, as a member of the executive branch ;-), do you have a method to
come up with a final decision on the direction for perl?  I think it's
all been discussed more than enough.

Dave

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

On Aug 12, 2014, at 10:28 AM, Daniel J. Luke  wrote:
> 
> On Aug 12, 2014, at 11:25 AM, Ryan Schmidt  wrote:
>> 
>>> that's pretty much why we're in the situation we are now - we just continue 
>>> with the current setup because it's 'easier'. Someone puts a bunch of 
>>> effort into making things work with a newer (but never the current) perl, 
>>> and then dev stops and we do the same dance later (but with even more 
>>> perls).
>> 
>> Would you prefer we do nothing, until someone has the time to do the massive 
>> job you propose?
> 
> I would prefer we spend time/effort working towards an end state that is an 
> improvement.

Mojca has said she has time for what she has proposed, and not for what you 
have proposed.


> I also reject your hypothesis that it's more effort to move to one perl than 
> it is to do these changes to perls 5.8, 5.10, 5.12, 5.14, 5.16, 5.18, and 5.20

My hope is that backporting an already-working patch to earlier perls would be 
easy. And revbumping all the modules is already planned, so that's no 
additional effort.


>> I think it's better to continue making incremental improvements, until that 
>> day comes.
> 
> sure, as long as they're incrementally working towards a goal instead of 
> working towards just adding yet more perl5.xx ports.

We are incrementally working toward the goal of updating perl module ports to 
newer versions, and adding newer perl versions to them thereby either verifying 
that they work with newer perls or in some cases uncovering problems that then 
get reported to the module's developers and get fixed.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 11:25 AM, Ryan Schmidt  wrote:
> 
>> that's pretty much why we're in the situation we are now - we just continue 
>> with the current setup because it's 'easier'. Someone puts a bunch of effort 
>> into making things work with a newer (but never the current) perl, and then 
>> dev stops and we do the same dance later (but with even more perls).
> 
> Would you prefer we do nothing, until someone has the time to do the massive 
> job you propose?

I would prefer we spend time/effort working towards an end state that is an 
improvement.

I also reject your hypothesis that it's more effort to move to one perl than it 
is to do these changes to perls 5.8, 5.10, 5.12, 5.14, 5.16, 5.18, and 5.20

> I think it's better to continue making incremental improvements, until that 
> day comes.

sure, as long as they're incrementally working towards a goal instead of 
working towards just adding yet more perl5.xx ports.

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

> On Aug 12, 2014, at 10:22 AM, Daniel J. Luke  wrote:
> 
> On Aug 12, 2014, at 11:19 AM, Ryan Schmidt  wrote:
>> 
>> 
>> On Aug 12, 2014, at 10:15 AM, Daniel J. Luke  wrote:
>>> 
>>> I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports 
>>> when it could be reduced (somewhat) by just working on p5.20... (and 
>>> deprecating/removing everything else).
>> 
>> It seems to me an order of magnitude more effort to reduce everything to 
>> "one perl" right now. I foresee each module port needing to be manually 
>> edited, plus overhauling the perl5 portgroup. Mojca's current proposal only 
>> requires revbumping each port, which can be automated to some degree.
> 
> that's pretty much why we're in the situation we are now - we just continue 
> with the current setup because it's 'easier'. Someone puts a bunch of effort 
> into making things work with a newer (but never the current) perl, and then 
> dev stops and we do the same dance later (but with even more perls).

Would you prefer we do nothing, until someone has the time to do the massive 
job you propose?

I think it's better to continue making incremental improvements, until that day 
comes.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

> On Aug 12, 2014, at 10:20 AM, David Evans  wrote:
> 
> On 8/12/14 8:06 AM, Ryan Schmidt wrote:
>> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec  wrote:
>>> Now about 5.8-5.16: my idea was to initially set the INC path for
>>> those versions in such a way that it would include
>>> "5.16.3/darwin-thread-multi-2level 5.16.3
>>> 5.16.1/darwin-thread-multi-2level 5.16.1
>>> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
>>> /5.16/ without the subrelease. That means that
>>> there would initially be no urgent need to revbump all the > 1000
>>> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
>>> would make sure to revbump all p5.18-foo ports.)
>>> 
>>> But I'm unable to figure out how to patch Perl to do that. The INC
>>> path additions seem to be ignored.
>> Why handle <= 5.16 differently than >= 5.18?
>> 
>> 
> Because we want them to go away? Or is the effort to do them all
> relatively trivial?
> 
> 

My assumption was that since a patch is already in place for perl5.20 and 
perl5.18 it could be backported to earlier versions with minimal effort, and 
that since Mojca plans a revbump of all perl modules anyway, before that mass 
revbumping would be the ideal time to do that.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 11:19 AM, Ryan Schmidt  wrote:
> 
> 
> On Aug 12, 2014, at 10:15 AM, Daniel J. Luke  wrote:
>> 
>> I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports when 
>> it could be reduced (somewhat) by just working on p5.20... (and 
>> deprecating/removing everything else).
> 
> It seems to me an order of magnitude more effort to reduce everything to "one 
> perl" right now. I foresee each module port needing to be manually edited, 
> plus overhauling the perl5 portgroup. Mojca's current proposal only requires 
> revbumping each port, which can be automated to some degree.

that's pretty much why we're in the situation we are now - we just continue 
with the current setup because it's 'easier'. Someone puts a bunch of effort 
into making things work with a newer (but never the current) perl, and then dev 
stops and we do the same dance later (but with even more perls).

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 8:06 AM, Ryan Schmidt wrote:
> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec  wrote:
>> Now about 5.8-5.16: my idea was to initially set the INC path for
>> those versions in such a way that it would include
>> "5.16.3/darwin-thread-multi-2level 5.16.3
>> 5.16.1/darwin-thread-multi-2level 5.16.1
>> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
>> /5.16/ without the subrelease. That means that
>> there would initially be no urgent need to revbump all the > 1000
>> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
>> would make sure to revbump all p5.18-foo ports.)
>>
>> But I'm unable to figure out how to patch Perl to do that. The INC
>> path additions seem to be ignored.
> Why handle <= 5.16 differently than >= 5.18?
>
>
Because we want them to go away? Or is the effort to do them all
relatively trivial?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Brandon Allbery]

On Tue, Aug 12, 2014 at 11:15 AM, Daniel J. Luke  wrote:

> I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports
> when it could be reduced (somewhat) by just working on p5.20... (and
> deprecating/removing everything else).


Also worth noting: the current Perl release cycle is such that 5.16 will
probably fall out of support upstream before everything is updated anyway;
probably better to concentrate our work on a later version with a longer
lifespan.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 7:56 AM, Mojca Miklavec wrote:
> On Tue, Aug 12, 2014 at 4:43 PM, David Evans wrote:
>> I'd be happy to help with this.  It's true that many ports are outdated
>> version-wise (even ones that have already been ported to p5.20)
>> and my recent experience suggests that many need updated
>> dependencies as well.
>>
>> To make things manageable, I would suggest limiting your initial changes in
>> a test branch to just your patches to the perl ports themselves
> Those are trivial.
>
>> and the
>> required rev bumps.
> That's all the > 300 ports. For all of those 300 (except for those
> added in the last few days) I actually checked for updates and already
> updated them instead of doing a revbump.
>
>> Getting everything up to date, 5.18, 5.20, etc can
>> then be handled as a separate process.
> Yes, I would do that later. But if people add 5.18 now, all those
> ports need to be revbumped as well.
>
> Now about 5.8-5.16: my idea was to initially set the INC path for
> those versions in such a way that it would include
> "5.16.3/darwin-thread-multi-2level 5.16.3
> 5.16.1/darwin-thread-multi-2level 5.16.1
> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
> /5.16/ without the subrelease. That means that
> there would initially be no urgent need to revbump all the > 1000
> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
> would make sure to revbump all p5.18-foo ports.)
>
> But I'm unable to figure out how to patch Perl to do that. The INC
> path additions seem to be ignored.
>
>> When testing has been completed and everyone is happy then you just
>> need to merge the then content of trunk to test and update your rev bumps
>> as necessary.  A tool to compare trunk versions to test versions would help
>> at this point. Then merge back to trunk, make a final check and commit.
>> No need to freeze trunk until you are ready to take these final steps.
>>
>> Again, I'd be glad to work with you to share the load both in merging and
>> testing and I'm sure there are others interested in perl who could help
>> as well.
> I will upload something today and/or create a branch.
>
> (But I really hate doing the merging.)
>
> Mojca
>
Given Daniel's input along with your comments,  looks like we need to stand
back for a second, see what's been done already, where we are going and
decide the steps to get there as a group.

The problems with people making changes behind your back can be minimized
by publishing what you are doing and asking people that want to make updates
to make them to trunk and to the test branch as well. 

But for the moment, I suggest that you commit all your proposed changes to
a new test branch so that it is more apparent where things stand.

As Daniel has said, no point in changing things that are going to go away so
we need to get a consensus on where we want to go with this.  My input here
would be this:

*  make the necessary changes to perl5.18 to work as perl5.20 does
*  leave perl5.16 and lower alone for now
*  update ports to support p5.18 & 5.20 unless there is strong sentiment
to go to 5.20 ASAP.
   not much difference in adding one or two new branches
*  then decided which branches to remove, go to single perl (which has
other consequences), etc.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

On Aug 12, 2014, at 10:15 AM, Daniel J. Luke  wrote:
> 
> I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports when 
> it could be reduced (somewhat) by just working on p5.20... (and 
> deprecating/removing everything else).

It seems to me an order of magnitude more effort to reduce everything to "one 
perl" right now. I foresee each module port needing to be manually edited, plus 
overhauling the perl5 portgroup. Mojca's current proposal only requires 
revbumping each port, which can be automated to some degree.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 11:12 AM, Ryan Schmidt  wrote:
> 
> 
> On Aug 12, 2014, at 10:08 AM, Daniel J. Luke  wrote:
> 
>> On Aug 12, 2014, at 11:06 AM, Ryan Schmidt  wrote:
>>> 
 But I'm unable to figure out how to patch Perl to do that. The INC
 path additions seem to be ignored.
>>> 
>>> Why handle <= 5.16 differently than >= 5.18?
>> 
>> why handle any of them?
>> 
>> maybe just spend the time fixing any ports that don't build with perl 5.20?
> 
> Yes, we will. Mojca has asked us to stop other changes to p5 ports until she 
> is done with this current task.

I'm just saying, it's a /lot/ of effort to do this for p5.8-p5.20 ports when it 
could be reduced (somewhat) by just working on p5.20... (and 
deprecating/removing everything else).

--
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

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Daniel J. Luke]

On Aug 12, 2014, at 11:11 AM, Ryan Schmidt  wrote:
> 
> It's still not totally automatic: the developer still has to update the 
> checksums, so if the developer is sufficiently aware that the checksums need 
> to be updated, why can't the developer also follow the stealth update recipe? 
> This hasn't been a problem before.

I don't necessarily disagree, but I also don't think it's a bad idea to at 
least think about possible ways to reduce friction for people contributing to 
MacPorts.

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

On Aug 12, 2014, at 10:08 AM, Daniel J. Luke  wrote:

> On Aug 12, 2014, at 11:06 AM, Ryan Schmidt  wrote:
>> 
>>> But I'm unable to figure out how to patch Perl to do that. The INC
>>> path additions seem to be ignored.
>> 
>> Why handle <= 5.16 differently than >= 5.18?
> 
> why handle any of them?
> 
> maybe just spend the time fixing any ports that don't build with perl 5.20?

Yes, we will. Mojca has asked us to stop other changes to p5 ports until she is 
done with this current task.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Ryan Schmidt]

On Aug 12, 2014, at 10:06 AM, Daniel J. Luke wrote:
> 
> On Aug 12, 2014, at 11:04 AM, Ryan Schmidt wrote:
>> 
>> On Aug 12, 2014, at 9:26 AM, Daniel J. Luke wrote:
>>> it wouldn't be horrible if setting a revision just changed dist_subdir 
>>> automatically (even when it's not necessary), which I think is what Sean 
>>> was suggesting.
>> 
>> In addition, a stealth update does not imply that the revision needs to be 
>> increased. Sometimes a change in a distfile does not warrant a rebuild. As 
>> explained in the recipe.
> 
> If I understand Sean right, he's just looking for areas where we can 
> automate/simplify processes. I don't really care about the specific case of 
> stealth-upgrades, but it would be possible to trade some disk 
> space/network/something else to make the process easier for portfile 
> developers.

Ideally, stealth updates should never occur. They do occur sometimes, and we 
should definitely take the opportunity when they do occur to educate developers 
about why they should never ever do that again. And I don't think we should 
make the MacPorts experience worse for users in the very normal situation of a 
revision increase occurring, just to slightly more automatically handle the 
very rare and undesirable situation of a stealth update. It's still not totally 
automatic: the developer still has to update the checksums, so if the developer 
is sufficiently aware that the checksums need to be updated, why can't the 
developer also follow the stealth update recipe? This hasn't been a problem 
before.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 11:06 AM, Ryan Schmidt  wrote:
> 
>> But I'm unable to figure out how to patch Perl to do that. The INC
>> path additions seem to be ignored.
> 
> Why handle <= 5.16 differently than >= 5.18?

why handle any of them?

maybe just spend the time fixing any ports that don't build with perl 5.20?

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

On Aug 12, 2014, at 9:56 AM, Mojca Miklavec  wrote:
> 
> Now about 5.8-5.16: my idea was to initially set the INC path for
> those versions in such a way that it would include
> "5.16.3/darwin-thread-multi-2level 5.16.3
> 5.16.1/darwin-thread-multi-2level 5.16.1
> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
> /5.16/ without the subrelease. That means that
> there would initially be no urgent need to revbump all the > 1000
> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
> would make sure to revbump all p5.18-foo ports.)
> 
> But I'm unable to figure out how to patch Perl to do that. The INC
> path additions seem to be ignored.

Why handle <= 5.16 differently than >= 5.18?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Daniel J. Luke]

On Aug 12, 2014, at 11:04 AM, Ryan Schmidt  wrote:
> 
> On Aug 12, 2014, at 9:26 AM, Daniel J. Luke wrote:
>> it wouldn't be horrible if setting a revision just changed dist_subdir 
>> automatically (even when it's not necessary), which I think is what Sean was 
>> suggesting.
> 
> In addition, a stealth update does not imply that the revision needs to be 
> increased. Sometimes a change in a distfile does not warrant a rebuild. As 
> explained in the recipe.

If I understand Sean right, he's just looking for areas where we can 
automate/simplify processes. I don't really care about the specific case of 
stealth-upgrades, but it would be possible to trade some disk 
space/network/something else to make the process easier for portfile developers.

--
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

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Ryan Schmidt]

On Aug 12, 2014, at 9:26 AM, Daniel J. Luke wrote:

> it wouldn't be horrible if setting a revision just changed dist_subdir 
> automatically (even when it's not necessary), which I think is what Sean was 
> suggesting.

In addition, a stealth update does not imply that the revision needs to be 
increased. Sometimes a change in a distfile does not warrant a rebuild. As 
explained in the recipe.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Ryan Schmidt]

On Aug 12, 2014, at 9:26 AM, Daniel J. Luke wrote:
> 
> On Aug 12, 2014, at 4:01 AM, Ryan Schmidt wrote:
>> 
>> On Aug 11, 2014, at 12:39 PM, Sean Farley wrote:
 Anyone who had the previous file, including our automated systems, will 
 now encounter a checksum mismatch. To fix this please follow the recipe 
 for stealth updates:
 
 http://trac.macports.org/wiki/PortfileRecipes#stealth-updates
>>> 
>>> Why isn't this automatically done for revision bumps? This seems like
>>> another task that is needlessly manual.
>> 
>> A revision increase does not imply that a stealth update has occurred. A 
>> stealth update is a rare occurrence and port authors must manually indicate 
>> in a port when this has happened because how would you suggest we 
>> automatically infer that this has happened?
> 
> it wouldn't be horrible if setting a revision just changed dist_subdir 
> automatically (even when it's not necessary), which I think is what Sean was 
> suggesting.

I think that would be horrible. It would unnecessarily re-mirror distfiles on 
our server and all mirrors, greatly increasing mirror disk space requirements 
for no reason. It would also impose re-downloads for all users, wasting 
everyone's bandwidth and time. Our current process works; let's not change it.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 4:43 PM, David Evans wrote:
>
> I'd be happy to help with this.  It's true that many ports are outdated
> version-wise (even ones that have already been ported to p5.20)
> and my recent experience suggests that many need updated
> dependencies as well.
>
> To make things manageable, I would suggest limiting your initial changes in
> a test branch to just your patches to the perl ports themselves

Those are trivial.

> and the
> required rev bumps.

That's all the > 300 ports. For all of those 300 (except for those
added in the last few days) I actually checked for updates and already
updated them instead of doing a revbump.

> Getting everything up to date, 5.18, 5.20, etc can
> then be handled as a separate process.

Yes, I would do that later. But if people add 5.18 now, all those
ports need to be revbumped as well.

Now about 5.8-5.16: my idea was to initially set the INC path for
those versions in such a way that it would include
"5.16.3/darwin-thread-multi-2level 5.16.3
5.16.1/darwin-thread-multi-2level 5.16.1
5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
/5.16/ without the subrelease. That means that
there would initially be no urgent need to revbump all the > 1000
ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
would make sure to revbump all p5.18-foo ports.)

But I'm unable to figure out how to patch Perl to do that. The INC
path additions seem to be ignored.

> When testing has been completed and everyone is happy then you just
> need to merge the then content of trunk to test and update your rev bumps
> as necessary.  A tool to compare trunk versions to test versions would help
> at this point. Then merge back to trunk, make a final check and commit.
> No need to freeze trunk until you are ready to take these final steps.
>
> Again, I'd be glad to work with you to share the load both in merging and
> testing and I'm sure there are others interested in perl who could help
> as well.

I will upload something today and/or create a branch.

(But I really hate doing the merging.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 4:30 PM, Daniel J. Luke wrote:
> On Aug 12, 2014, at 10:15 AM, Mojca Miklavec wrote:
>>
>> Other than that I can definitely create a new branch to simplify
>> testing and add the same patch to all perl versions. But the request
>> to wait with updates a bit (unless it's really really really needed)
>> still stands.
>
> you could create a branch with just the most recent upstream perl (currently 
> perl5.20.0) and interested parties could test that maybe?
>
> probably simpler than trying to do stuff for each of the perl5 versions we 
> currently have (and hopefully gets us to 'one perl' more quickly?)

I would say "let's solve one problem at a time". At this time I
believe it will be least painful and most efficient to simply add 5.18
and 5.20 to all modules. But before this is added I would *really*
like to get rid of the subrelease number(s).

Then we can make Perl 5.20 default (just to confuse everyone working
on https://trac.macports.org/ticket/44405) etc.


Yes, I still believe that we need to implement something to fetch the
latest version of all modules automatically from CPAN etc. And maybe
do some drastic changes to Perl packaging. But this is not something
that I'm currently able to implement quickly and this can wait.

Btw: some modules like p5-wx are broken in Perl 5.20. Having 5.18
available may help in such situations.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 7:15 AM, Mojca Miklavec wrote:
> On Tue, Aug 12, 2014 at 3:02 PM, David Evans wrote:
>> On 8/12/14 5:34 AM, Ryan Schmidt wrote:
>>> On Aug 12, 2014, at 4:15 AM, Mojca Miklavec wrote:
 Hi,

 I would like to do a massive commit with changes in perl modules.

 I attached a patch to
https://trac.macports.org/ticket/43480
 two days ago, but it is no longer suitable as such out-of-the-box
 since there were a bunch of changes in perl modules (including
 changing exactly the files that I previously edited in that patch). I
 need to revbump all the modules that were committed in-between and
 merge some changes.

 I would really really really like to see the switch from
/opt/local/lib/perl5/5.18.2
 to
/opt/local/lib/perl5/5.18

 and I already implemented that for perl 5.18 to do a complete switch
 getting rid of the subrelease number. However this mass-update change
 would also be the most suitable time to do the same with Perl 5.16.
 There I would switch the default path, revbump dependent ports
 (linking against libperl.dylib), but I would keep the line

 configure.args-append "-D
 inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
 5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
 5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""

 for now to avoid having to revbump all the thousand files at once.

 That would greatly reduce problems like

 --->  Scanning binaries for linking errors
 Could not open 
 /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
 Error opening or reading file (referenced from
 /opt/local/apache2/libexec/mod_perl.so)

 and having "problems" with perl modules installing files to different
 subdirectories.

 I just wanted to check if anyone has anything *against* this change in
 5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
 least not as a high priority. But Perl 5.16 is on the borderline
 (currently the only one supported ) The idea would be to get rid of
 support for those old Perl modules anyway.

 (But if anyone wants, I can change older perl versions as well.)

 I would be really grateful if you could hold off committing to the
 perl modules at least a tiny bit. I tested my changes on Saturday, but
 if too many changes are committed, that will all be double work.

 My plan would be to add 5.18 and 5.20 to other modules once this gets
 committed, but we first need to revbump all modules that are already
 depending on 5.18 if we want to get rid of the subrelease number
 completely.
>>> If you're going to revbump all perl modules, you may as well make this 
>>> change in all versions of perl, not just 5.16 and up, no? Otherwise you're 
>>> revbumping p5.14-* and below for no reason.
>> +1 for Ryan here.  This will be a massive rebuild and I would prefer to
>> see it done once only after you have all the perl versions modified.
>>
>> Also, I still think it would be prudent to make these changes in a test
>> branch first so that they can be tested in a wider group, voluntarily,
>> before committing to trunk.  This would also obviate the need to stop
>> current updates in trunk as these can be easily merged into the test
>> branch as necessary.
> And who is volunteering to do the merging? That's a serious question
> because I'm most certainly not. The problem is that I need to either
> revbump or upgrade every single Perl package. I can upgrade the
> package in the test branch, but when someone else makes exactly the
> same upgrade in the trunk before the "merge", one needs to revbump the
> updated port. So it's not really trivial to merge the changes.
I'd be happy to help with this.  It's true that many ports are outdated
version-wise (even ones that have already been ported to p5.20)
and my recent experience suggests that many need updated
dependencies as well.

To make things manageable, I would suggest limiting your initial changes in
a test branch to just your patches to the perl ports themselves and the
required rev bumps. Getting everything up to date, 5.18, 5.20, etc can
then be handled as a separate process.

When testing has been completed and everyone is happy then you just
need to merge the then content of trunk to test and update your rev bumps
as necessary.  A tool to compare trunk versions to test versions would help
at this point. Then merge back to trunk, make a final check and commit. 
No need to freeze trunk until you are ready to take these final steps.

Again, I'd be glad to work with you to share the load both in merging and
testing and I'm sure there are others interested in perl who could help
as well.
>
> Other than that I can definitely create a new branch to simplify
> testing and add the same patch to all perl versions. 
Great.  I look f

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 10:15 AM, Mojca Miklavec  wrote:
> 
> Other than that I can definitely create a new branch to simplify
> testing and add the same patch to all perl versions. But the request
> to wait with updates a bit (unless it's really really really needed)
> still stands.

you could create a branch with just the most recent upstream perl (currently 
perl5.20.0) and interested parties could test that maybe? 

probably simpler than trying to do stuff for each of the perl5 versions we 
currently have (and hopefully gets us to 'one perl' more quickly?)

--
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

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Daniel J. Luke]

On Aug 12, 2014, at 4:01 AM, Ryan Schmidt  wrote:
> 
> On Aug 11, 2014, at 12:39 PM, Sean Farley wrote:
>>> Anyone who had the previous file, including our automated systems, will now 
>>> encounter a checksum mismatch. To fix this please follow the recipe for 
>>> stealth updates:
>>> 
>>> http://trac.macports.org/wiki/PortfileRecipes#stealth-updates
>> 
>> Why isn't this automatically done for revision bumps? This seems like
>> another task that is needlessly manual.
> 
> A revision increase does not imply that a stealth update has occurred. A 
> stealth update is a rare occurrence and port authors must manually indicate 
> in a port when this has happened because how would you suggest we 
> automatically infer that this has happened?

it wouldn't be horrible if setting a revision just changed dist_subdir 
automatically (even when it's not necessary), which I think is what Sean was 
suggesting.

--
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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 3:02 PM, David Evans wrote:
> On 8/12/14 5:34 AM, Ryan Schmidt wrote:
>> On Aug 12, 2014, at 4:15 AM, Mojca Miklavec wrote:
>>> Hi,
>>>
>>> I would like to do a massive commit with changes in perl modules.
>>>
>>> I attached a patch to
>>>https://trac.macports.org/ticket/43480
>>> two days ago, but it is no longer suitable as such out-of-the-box
>>> since there were a bunch of changes in perl modules (including
>>> changing exactly the files that I previously edited in that patch). I
>>> need to revbump all the modules that were committed in-between and
>>> merge some changes.
>>>
>>> I would really really really like to see the switch from
>>>/opt/local/lib/perl5/5.18.2
>>> to
>>>/opt/local/lib/perl5/5.18
>>>
>>> and I already implemented that for perl 5.18 to do a complete switch
>>> getting rid of the subrelease number. However this mass-update change
>>> would also be the most suitable time to do the same with Perl 5.16.
>>> There I would switch the default path, revbump dependent ports
>>> (linking against libperl.dylib), but I would keep the line
>>>
>>> configure.args-append "-D
>>> inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
>>> 5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
>>> 5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""
>>>
>>> for now to avoid having to revbump all the thousand files at once.
>>>
>>> That would greatly reduce problems like
>>>
>>> --->  Scanning binaries for linking errors
>>> Could not open 
>>> /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
>>> Error opening or reading file (referenced from
>>> /opt/local/apache2/libexec/mod_perl.so)
>>>
>>> and having "problems" with perl modules installing files to different
>>> subdirectories.
>>>
>>> I just wanted to check if anyone has anything *against* this change in
>>> 5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
>>> least not as a high priority. But Perl 5.16 is on the borderline
>>> (currently the only one supported ) The idea would be to get rid of
>>> support for those old Perl modules anyway.
>>>
>>> (But if anyone wants, I can change older perl versions as well.)
>>>
>>> I would be really grateful if you could hold off committing to the
>>> perl modules at least a tiny bit. I tested my changes on Saturday, but
>>> if too many changes are committed, that will all be double work.
>>>
>>> My plan would be to add 5.18 and 5.20 to other modules once this gets
>>> committed, but we first need to revbump all modules that are already
>>> depending on 5.18 if we want to get rid of the subrelease number
>>> completely.
>> If you're going to revbump all perl modules, you may as well make this 
>> change in all versions of perl, not just 5.16 and up, no? Otherwise you're 
>> revbumping p5.14-* and below for no reason.
>
> +1 for Ryan here.  This will be a massive rebuild and I would prefer to
> see it done once only after you have all the perl versions modified.
>
> Also, I still think it would be prudent to make these changes in a test
> branch first so that they can be tested in a wider group, voluntarily,
> before committing to trunk.  This would also obviate the need to stop
> current updates in trunk as these can be easily merged into the test
> branch as necessary.

And who is volunteering to do the merging? That's a serious question
because I'm most certainly not. The problem is that I need to either
revbump or upgrade every single Perl package. I can upgrade the
package in the test branch, but when someone else makes exactly the
same upgrade in the trunk before the "merge", one needs to revbump the
updated port. So it's not really trivial to merge the changes.

Other than that I can definitely create a new branch to simplify
testing and add the same patch to all perl versions. But the request
to wait with updates a bit (unless it's really really really needed)
still stands.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[Clemens Lang]

Hi,

> Condition number 1 in the BSD license is that the copyright notices must
> be preserved. If there's any doubt about whether some code you have
> copied is sufficiently large and/or creative to be subject to copyright,
> assume it is and preserve the notices. That's not an onerous task.

you're right, that's a reasonable approach. Restored the copyright to what
it was in r123687.

I guess we can consider this matter settled now?

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[Joshua Root]

On 2014-8-12 22:47 , David Evans wrote:
> On 8/12/14 5:04 AM, Clemens Lang wrote:
>> Hi,
>>
>>> Of course, a sure fire approach would be to see if Berry would be
>>> willing to assign any copyright interest he might have in the code
>>> to The MacPorts Project.
>> That might be the case for US jurisdictions, but not for the EU. For
>> example, as a German citizen, I cannot assign my copyright – it will
>> always be mine. I can grant usage rights, but that's different.
>>
>> Of course other organizations (such as, e.g., the GNU project) do it
>> anyway – I'm just saying if we're going to open that can of worms,
>> we can either
>>  (a) do it the full-blown way, employ a few lawyers across borders,
>>  draft a document and have everybody submit that before
>>  accepting patches. I think this would considerably slow down
>>  our (already slow) processes.
>>  (b) continue to ignore the issue as we have so far in the interest
>>  of simplicity.
>> Obviously (a) would be the correct thing to do. Unfortunately,
>> "correct" costs time, and eats up more of the time we could use to
>> get stuff done that actually matters.
>>
>> So, if you care enough about the issue, feel free to revert the
>> change. Cc'ing jberry, because, if any, his rights are being
>> violated here.
>>
> Interesting.
> 
> Yes, I think conferring with Berry is the appropriate approach.  If he
> doesn't mind then the issue is moot.

Condition number 1 in the BSD license is that the copyright notices must
be preserved. If there's any doubt about whether some code you have
copied is sufficiently large and/or creative to be subject to copyright,
assume it is and preserve the notices. That's not an onerous task.

I don't think that getting permission from specific contributors to
distribute their code under a different license is a path we want to go
down.

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[David Evans]

On 8/12/14 5:34 AM, Ryan Schmidt wrote:
> On Aug 12, 2014, at 4:15 AM, Mojca Miklavec wrote:
>> Hi,
>>
>> I would like to do a massive commit with changes in perl modules.
>>
>> I attached a patch to
>>https://trac.macports.org/ticket/43480
>> two days ago, but it is no longer suitable as such out-of-the-box
>> since there were a bunch of changes in perl modules (including
>> changing exactly the files that I previously edited in that patch). I
>> need to revbump all the modules that were committed in-between and
>> merge some changes.
>>
>> I would really really really like to see the switch from
>>/opt/local/lib/perl5/5.18.2
>> to
>>/opt/local/lib/perl5/5.18
>>
>> and I already implemented that for perl 5.18 to do a complete switch
>> getting rid of the subrelease number. However this mass-update change
>> would also be the most suitable time to do the same with Perl 5.16.
>> There I would switch the default path, revbump dependent ports
>> (linking against libperl.dylib), but I would keep the line
>>
>> configure.args-append "-D
>> inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
>> 5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
>> 5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""
>>
>> for now to avoid having to revbump all the thousand files at once.
>>
>> That would greatly reduce problems like
>>
>> --->  Scanning binaries for linking errors
>> Could not open 
>> /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
>> Error opening or reading file (referenced from
>> /opt/local/apache2/libexec/mod_perl.so)
>>
>> and having "problems" with perl modules installing files to different
>> subdirectories.
>>
>> I just wanted to check if anyone has anything *against* this change in
>> 5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
>> least not as a high priority. But Perl 5.16 is on the borderline
>> (currently the only one supported ) The idea would be to get rid of
>> support for those old Perl modules anyway.
>>
>> (But if anyone wants, I can change older perl versions as well.)
>>
>> I would be really grateful if you could hold off committing to the
>> perl modules at least a tiny bit. I tested my changes on Saturday, but
>> if too many changes are committed, that will all be double work.
>>
>> My plan would be to add 5.18 and 5.20 to other modules once this gets
>> committed, but we first need to revbump all modules that are already
>> depending on 5.18 if we want to get rid of the subrelease number
>> completely.
> If you're going to revbump all perl modules, you may as well make this change 
> in all versions of perl, not just 5.16 and up, no? Otherwise you're 
> revbumping p5.14-* and below for no reason.
>
>
>
+1 for Ryan here.  This will be a massive rebuild and I would prefer to
see it done once only after you have all the perl versions modified.

Also, I still think it would be prudent to make these changes in a test
branch first so that they can be tested in a wider group, voluntarily,
before committing to trunk.  This would also obviate the need to stop
current updates in trunk as these can be easily merged into the test
branch as necessary.  Then when all is ready and interested parties sign
off, the test branch can be merged to trunk.

Dave

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[David Evans]

On 8/12/14 5:04 AM, Clemens Lang wrote:
> Hi,
>
>> Of course, a sure fire approach would be to see if Berry would be
>> willing to assign any copyright interest he might have in the code
>> to The MacPorts Project.
> That might be the case for US jurisdictions, but not for the EU. For
> example, as a German citizen, I cannot assign my copyright – it will
> always be mine. I can grant usage rights, but that's different.
>
> Of course other organizations (such as, e.g., the GNU project) do it
> anyway – I'm just saying if we're going to open that can of worms,
> we can either
>  (a) do it the full-blown way, employ a few lawyers across borders,
>  draft a document and have everybody submit that before
>  accepting patches. I think this would considerably slow down
>  our (already slow) processes.
>  (b) continue to ignore the issue as we have so far in the interest
>  of simplicity.
> Obviously (a) would be the correct thing to do. Unfortunately,
> "correct" costs time, and eats up more of the time we could use to
> get stuff done that actually matters.
>
> So, if you care enough about the issue, feel free to revert the
> change. Cc'ing jberry, because, if any, his rights are being
> violated here.
>
Interesting.

Yes, I think conferring with Berry is the appropriate approach.  If he
doesn't mind then the issue is moot.

Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Ryan Schmidt]

On Aug 12, 2014, at 4:15 AM, Mojca Miklavec wrote:
> 
> Hi,
> 
> I would like to do a massive commit with changes in perl modules.
> 
> I attached a patch to
>https://trac.macports.org/ticket/43480
> two days ago, but it is no longer suitable as such out-of-the-box
> since there were a bunch of changes in perl modules (including
> changing exactly the files that I previously edited in that patch). I
> need to revbump all the modules that were committed in-between and
> merge some changes.
> 
> I would really really really like to see the switch from
>/opt/local/lib/perl5/5.18.2
> to
>/opt/local/lib/perl5/5.18
> 
> and I already implemented that for perl 5.18 to do a complete switch
> getting rid of the subrelease number. However this mass-update change
> would also be the most suitable time to do the same with Perl 5.16.
> There I would switch the default path, revbump dependent ports
> (linking against libperl.dylib), but I would keep the line
> 
> configure.args-append "-D
> inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
> 5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
> 5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""
> 
> for now to avoid having to revbump all the thousand files at once.
> 
> That would greatly reduce problems like
> 
> --->  Scanning binaries for linking errors
> Could not open 
> /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
> Error opening or reading file (referenced from
> /opt/local/apache2/libexec/mod_perl.so)
> 
> and having "problems" with perl modules installing files to different
> subdirectories.
> 
> I just wanted to check if anyone has anything *against* this change in
> 5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
> least not as a high priority. But Perl 5.16 is on the borderline
> (currently the only one supported ) The idea would be to get rid of
> support for those old Perl modules anyway.
> 
> (But if anyone wants, I can change older perl versions as well.)
> 
> I would be really grateful if you could hold off committing to the
> perl modules at least a tiny bit. I tested my changes on Saturday, but
> if too many changes are committed, that will all be double work.
> 
> My plan would be to add 5.18 and 5.20 to other modules once this gets
> committed, but we first need to revbump all modules that are already
> depending on 5.18 if we want to get rid of the subrelease number
> completely.

If you're going to revbump all perl modules, you may as well make this change 
in all versions of perl, not just 5.16 and up, no? Otherwise you're revbumping 
p5.14-* and below for no reason.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[Clemens Lang]

Hi,

> Of course, a sure fire approach would be to see if Berry would be
> willing to assign any copyright interest he might have in the code
> to The MacPorts Project.

That might be the case for US jurisdictions, but not for the EU. For
example, as a German citizen, I cannot assign my copyright – it will
always be mine. I can grant usage rights, but that's different.

Of course other organizations (such as, e.g., the GNU project) do it
anyway – I'm just saying if we're going to open that can of worms,
we can either
 (a) do it the full-blown way, employ a few lawyers across borders,
 draft a document and have everybody submit that before
 accepting patches. I think this would considerably slow down
 our (already slow) processes.
 (b) continue to ignore the issue as we have so far in the interest
 of simplicity.
Obviously (a) would be the correct thing to do. Unfortunately,
"correct" costs time, and eats up more of the time we could use to
get stuff done that actually matters.

So, if you care enough about the issue, feel free to revert the
change. Cc'ing jberry, because, if any, his rights are being
violated here.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[David Evans]

On 8/12/14 4:13 AM, Clemens Lang wrote:
> Hey,
>
>> The file name line should be removed (here and everywhere else, really) and
>> the standard MacPorts modeline inserted instead of this very short one.
> I agree, r123675.
>
>>> +# Copyright (c) 2007, 2009, 2011 The MacPorts Project
>>> +# Copyright (c) 2007 James D. Berry
>> I think we just need the MacPorts copyright line with 2014 as the year, and
>> James Berry's copyright line removed. But IANAL and I'm actually not sure
>> how copyright lines should be handled in the case of files that are based on
>> other files.
> Neither am I, but I took the risk here in r123675.
>
IANAL either but I have managed projects where this sort of thing was an
issue and
IP lawyers were involved.

The key is that copyrights protect the expression of an idea not the
idea itself (as a patent would).
Therefore, the copyright protects the literal text not an algorithm.

The test then is whether any recognizable sequence of code from the
original remains.  Small
fragments that might occur in any code and cannot be written otherwise
may be dismissed.

Of course, a sure fire approach would be to see if Berry would be
willing to assign any copyright
interest he might have in the code to The MacPorts Project.

Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[Clemens Lang]

Hey,

> The file name line should be removed (here and everywhere else, really) and
> the standard MacPorts modeline inserted instead of this very short one.

I agree, r123675.

> > +# Copyright (c) 2007, 2009, 2011 The MacPorts Project
> > +# Copyright (c) 2007 James D. Berry
> 
> I think we just need the MacPorts copyright line with 2014 as the year, and
> James Berry's copyright line removed. But IANAL and I'm actually not sure
> how copyright lines should be handled in the case of files that are based on
> other files.

Neither am I, but I took the risk here in r123675.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123673] trunk/base/src

[Ryan Schmidt]

On Aug 12, 2014, at 5:25 AM, c...@macports.org wrote:

> Revision
> 123673
> Author
> c...@macports.org
> Date
> 2014-08-12 03:25:35 -0700 (Tue, 12 Aug 2014)
> Log Message
> 
> base: Add port reload, closes #36054, patch from #42487

Thanks!

> --- trunk/base/src/port1.0/portreload.tcl (rev 0)
> +++ trunk/base/src/port1.0/portreload.tcl 2014-08-12 10:25:35 UTC (rev 
> 123673)
> 
> @@ -0,0 +1,68 @@
> 
> +# et:ts=4
> +# portreload.tcl
> +# $Id$

The file name line should be removed (here and everywhere else, really) and the 
standard MacPorts modeline inserted instead of this very short one.

> +# Copyright (c) 2007, 2009, 2011 The MacPorts Project
> +# Copyright (c) 2007 James D. Berry

I think we just need the MacPorts copyright line with 2014 as the year, and 
James Berry's copyright line removed. But IANAL and I'm actually not sure how 
copyright lines should be handled in the case of files that are based on other 
files.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Perl changes (+ please wait a bit with commits in perl modules if possible)

[Mojca Miklavec]

Hi,

I would like to do a massive commit with changes in perl modules.

I attached a patch to
https://trac.macports.org/ticket/43480
two days ago, but it is no longer suitable as such out-of-the-box
since there were a bunch of changes in perl modules (including
changing exactly the files that I previously edited in that patch). I
need to revbump all the modules that were committed in-between and
merge some changes.

I would really really really like to see the switch from
/opt/local/lib/perl5/5.18.2
to
/opt/local/lib/perl5/5.18

and I already implemented that for perl 5.18 to do a complete switch
getting rid of the subrelease number. However this mass-update change
would also be the most suitable time to do the same with Perl 5.16.
There I would switch the default path, revbump dependent ports
(linking against libperl.dylib), but I would keep the line

configure.args-append "-D
inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""

for now to avoid having to revbump all the thousand files at once.

That would greatly reduce problems like

--->  Scanning binaries for linking errors
Could not open 
/opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
Error opening or reading file (referenced from
/opt/local/apache2/libexec/mod_perl.so)

and having "problems" with perl modules installing files to different
subdirectories.

I just wanted to check if anyone has anything *against* this change in
5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
least not as a high priority. But Perl 5.16 is on the borderline
(currently the only one supported ) The idea would be to get rid of
support for those old Perl modules anyway.

(But if anyone wants, I can change older perl versions as well.)

I would be really grateful if you could hold off committing to the
perl modules at least a tiny bit. I tested my changes on Saturday, but
if too many changes are committed, that will all be double work.

My plan would be to add 5.18 and 5.20 to other modules once this gets
committed, but we first need to revbump all modules that are already
depending on 5.18 if we want to get rid of the subrelease number
completely.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Ryan Schmidt]

On Aug 11, 2014, at 12:39 PM, Sean Farley wrote:

> Ryan Schmidt writes:
> 
>> Anyone who had the previous file, including our automated systems, will now 
>> encounter a checksum mismatch. To fix this please follow the recipe for 
>> stealth updates:
>> 
>> http://trac.macports.org/wiki/PortfileRecipes#stealth-updates
> 
> Why isn't this automatically done for revision bumps? This seems like
> another task that is needlessly manual.

A revision increase does not imply that a stealth update has occurred. A 
stealth update is a rare occurrence and port authors must manually indicate in 
a port when this has happened because how would you suggest we automatically 
infer that this has happened?



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev