perl5.20

[Daniel J. Luke]

Note that this thread has now devolved into discussing (bikeshedding?) the longer-term TODO ideas on the list, while conveniently ignoring the steps we can take /today/ to make the perl situation in MacPorts better. 

On Jul 31, 2014, at 3:15 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Jul 31, 2014, at 2:04 PM, Daniel J. Luke <dluke at geeklair.net> wrote:
>> On Jul 31, 2014, at 2:50 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>> On Jul 28, 2014, at 6:35 PM, Daniel J. Luke wrote:
>>>>>> TODO:
>>>>>> - some way to mass rev-bump/force rebuild/force reinstall of all p5 ports when the perl5 port changes (ideally something that could be done from within the perl5 portgroup, so it can be done in one place)
>>>>> 
>>>>> That's what I suggested a few posts back. And I was told that this is
>>>>> a problem because one would have to modify all the thousand ports
>>>>> anyway, else index wouldn't see any chance.
>>>> 
>>>> We may have to modify base and/or just portindex to make this possible (that's why I put it under 'TODO' :-) ).
>>> 
>>> I don't see what change could be made to base or portgroup that would change the necessity for each individual port getting a revision increase.
>>> 
>>> Imagine p5-whatever is installed and uses perl 5.20. Now we want to update to 5.22. p5-whatever's version, revision or epoch will need to increase so that users will see the port in "port outdated". And the revision is the correct value to change for this situation. There's no way for base or portgroup to know what the correct revision is for each individual p5 port; they must each declare it themselves.
>> 
>> with the current code, that's the case.
>> 
>> The portgroup could possibly set revision/epoch to something (datestamp) and we could recommend that individual ports do the same (so they can easily override the portgroup). base/portindex may need to be enhanced to process an epoch/revision that's set in the portgroup, though (I haven't checked this).
> 
> It's not appropriate for a portgroup to appropriate the version, revision or epoch for its own purposes. These all have defined meanings that each individual port is completely responsible for updating.
> 
> version: updated when a new version of the software is released by its developers
> epoch: increased when the version number appears to vercmp to decrease
> revision: increased when the maintainer makes a change that requires a rebuild before a new version is released

so revision is the right one to use, then, but you don't want it to be used this way?

I want to make it easier to say "this port has changed in a way that requires any port that depends on it needs to be rebuilt" - this is currently done by manually rev-bumping all the dependent ports, forgetting a few, having rev-upgrade catch them on people's machines, and eventually manually updating the ones that were missed.

>> Similarly, it would be possible to do something like add a trigger to do a +1 in revision to any ports that use the perl5 portgroup if that were better.
> 
> So when updating to 5.22, you propose that all p5 ports forever lose the ability to be revision 0?
> And when updating to 5.24, all p5 ports lose the ability to be revision 1?
> And so on until the end of time?

sure, why does it matter what the revision is?

I earlier suggested (ab)using epoch by having the portgroup set it to YYYYMMDD (or YYYYMMDDXX) when we commit a new perl version. We could do it with revision instead. I believe this would require a change to portindex, but I haven't checked. It would simply be policy for ports that use the perl5 portgroup to use the same format when setting their own revisions for reasons not due to perl5 upgrades.

>> A generic solution would be for an individual port to be able to indicate that all ports that depend on it need to be rebuilt
> 
> And again: what criterion would "port outdated" use to determine that a rebuild needs to occur?

Again, I've suggested using both revision and epoch in the perl5 portgroup + any necessary changes to base/portindex for this.

> The criteria we currently use are version, revision, epoch, and platform, so it sounds like you're suggesting the addition of a 5th criterion.

that would be one way to implement it. I don't actually care how it's done - it's something that would be useful to express.

certainly one way would be to add a variable (abi_version_compatibility or something) and act on it.

>>> Various scripts have previously been developed to edit portfiles to increase ports' revisions automatically.
>> 
>> link? is there one in the repo? do we trust it enough to (frequently) run it on the crap-ton of p5 ports [of which there may end up being many, many more]?
> 
> Such scripts have been posted on the mailing list and attached to various update tickets. I don't have a particular one handy. I don't know if one was ever committed to the repository anywhere. I was suggesting we could try to revive one of those scripts and make it more general-purpose and robust as a possible solution for the problem.
> 
> It may be very hard to write a script that could accommodate all the weird things we can do with Tcl in portfiles (like my php portfile) but fortunately the p5 ports are quite simple by comparison.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+