Pre-commit script to reject commits

Ryan Schmidt ryandesign at macports.org
Fri Mar 7 11:07:25 PST 2008


On Mar 7, 2008, at 12:24, Rainer Müller wrote:

> Blair Zajac wrote:
>
>> If you have the base port installed, say libfoo, but it's not  
>> listed as a
>> dependency, then if you remove it, then you'll unintentionally  
>> break any ports
>> that picked up a dependency upon it at configure time.
>
> Thanks for the clarification, I think you are kind of right. But it  
> will
> always hit someone not affected by the update. For example, changing
> depends_* inside some variants and incrementing the revsion forces all
> users to recompile - even if they don't use this variant...

And yet, incrementing the revision is the correct thing to do, if  
doing so will fix the install for even just a few users, even at the  
risk of unnecessarily rebuilding the port for others. For example,  
perl5.8 was updated from revision 1 to 2 in r34508. As I understand  
it, the change was irrelevant for those using gcc 4.0 (i.e. at least  
all Mac users), but was necessary for those using gcc 4.2 (perhaps  
Linux or FreeBSD users). Oh well.

I'm not sure such a pre-commit hook is practical to write. How would  
one write it?

> As an additional comment, I don't think port lint is yet stable enough
> to be used as a commit filter (rejecting commits not passing port  
> lint).

I agree, but my plan wasn't ever to reject commits based on port  
lint. It should be as it is now: an informational post-commit task.



More information about the macports-dev mailing list