Re: Pre-commit script to reject commits
Blair Zajac wrote: I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision. I don't see why changing depends_* should change the revision. Either it prevented the installation at all or users installed the dependency by hand before. It doesn't change the files which are going to be installed. Incrementing the revision would force them to do an unnecessary recompile. The only thing I can think of is that the output of `port dependents' could be 'wrong'. But that's reflecting the state of the port as it was installed, so it is kind of correct. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Pre-commit script to reject commits
Rainer Müller wrote: Blair Zajac wrote: I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision. I don't see why changing depends_* should change the revision. Either it prevented the installation at all or users installed the dependency by hand before. It doesn't change the files which are going to be installed. Incrementing the revision would force them to do an unnecessary recompile. The only thing I can think of is that the output of `port dependents' could be 'wrong'. But that's reflecting the state of the port as it was installed, so it is kind of correct. 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. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Pre-commit script to reject commits
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Pre-commit script to reject commits
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 don't think we're all have the same understanding of when the port revision number should be incremented. If there are guidelines we could all agree to it could be documented, and (along with some nagging) we'd probably see a lot less variance, not that automation wouldn't be fine too. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
