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