On Sep 8, 2007, at 08:58, source_changes@macosforge.org wrote:
Revision: 28760 http://trac.macosforge.org/projects/macports/changeset/28760 Author: nox@macports.org Date: 2007-09-08 06:58:45 -0700 (Sat, 08 Sep 2007)
Log Message: ----------- libtool: * Added standard doc install.
Please don't forget to increment the port revision when you make a change that causes the port to install different files. I've been fixing this on the ones you've just committed.
* Removed obsolete configure args and darwin 6 platform.
Why was the darwin 6 platform removed? Do you have knowledge that it does not function anymore, or is not necessary anymore on darwin 6? Unless you do, darwin 6 platforms should be left in place. The latest consensus on darwin 6 was that although it is no longer a supported platform, we would still accept patches to fix things for darwin 6, and we should not deliberately break darwin 6. At least that's what I recall. If we want to change that policy now, then let's discuss that (and document the outcome in the guide of course).
* Fixed livecheck.
Modified Paths: -------------- trunk/dports/devel/libtool/Portfile
[snip]
Le 8 sept. 07 à 22:04, Ryan Schmidt a écrit :
On Sep 8, 2007, at 08:58, source_changes@macosforge.org wrote:
Revision: 28760 http://trac.macosforge.org/projects/macports/changeset/ 28760 Author: nox@macports.org Date: 2007-09-08 06:58:45 -0700 (Sat, 08 Sep 2007)
Log Message: ----------- libtool: * Added standard doc install.
Please don't forget to increment the port revision when you make a change that causes the port to install different files. I've been fixing this on the ones you've just committed.
From what I've understood until now, documentation files is not relevant enough to increase revision number. Nevertheless, it would not hurt that much to increase it and i have never done it because i thought that was the current policy, thanks again for noticing me it's not.
* Removed obsolete configure args and darwin 6 platform.
Why was the darwin 6 platform removed? Do you have knowledge that it does not function anymore, or is not necessary anymore on darwin 6? Unless you do, darwin 6 platforms should be left in place. The latest consensus on darwin 6 was that although it is no longer a supported platform, we would still accept patches to fix things for darwin 6, and we should not deliberately break darwin 6. At least that's what I recall. If we want to change that policy now, then let's discuss that (and document the outcome in the guide of course).
I thought unsupported things should be removed from portfiles. Out of curiosity, does base still build on darwin 6?
* Fixed livecheck.
Modified Paths: -------------- trunk/dports/devel/libtool/Portfile
[snip]
-- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Sep 8, 2007, at 9:39 PM, N_Ox wrote:
Le 8 sept. 07 à 22:04, Ryan Schmidt a écrit :
On Sep 8, 2007, at 08:58, source_changes@macosforge.org wrote:
Revision: 28760 http://trac.macosforge.org/projects/macports/changeset/ 28760 Author: nox@macports.org Date: 2007-09-08 06:58:45 -0700 (Sat, 08 Sep 2007)
Log Message: ----------- libtool: * Added standard doc install.
Please don't forget to increment the port revision when you make a change that causes the port to install different files. I've been fixing this on the ones you've just committed.
From what I've understood until now, documentation files is not relevant enough to increase revision number. Nevertheless, it would not hurt that much to increase it and i have never done it because i thought that was the current policy, thanks again for noticing me it's not.
* Removed obsolete configure args and darwin 6 platform.
Why was the darwin 6 platform removed? Do you have knowledge that it does not function anymore, or is not necessary anymore on darwin 6? Unless you do, darwin 6 platforms should be left in place. The latest consensus on darwin 6 was that although it is no longer a supported platform, we would still accept patches to fix things for darwin 6, and we should not deliberately break darwin 6. At least that's what I recall. If we want to change that policy now, then let's discuss that (and document the outcome in the guide of course).
I thought unsupported things should be removed from portfiles. Out of curiosity, does base still build on darwin 6?
Unless we know for sure that it doesn't work, we should leave the support in there. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On Sep 9, 2007, at 06:55, Blair Zajac wrote:
On Sep 8, 2007, at 9:39 PM, N_Ox wrote:
Le 8 sept. 07 à 22:04, Ryan Schmidt a écrit :
On Sep 8, 2007, at 08:58, source_changes@macosforge.org wrote:
Revision: 28760 http://trac.macosforge.org/projects/macports/changeset/ 28760 Author: nox@macports.org Date: 2007-09-08 06:58:45 -0700 (Sat, 08 Sep 2007)
Log Message: ----------- libtool: * Added standard doc install.
Please don't forget to increment the port revision when you make a change that causes the port to install different files. I've been fixing this on the ones you've just committed.
From what I've understood until now, documentation files is not relevant enough to increase revision number. Nevertheless, it would not hurt that much to increase it and i have never done it because i thought that was the current policy, thanks again for noticing me it's not.
* Removed obsolete configure args and darwin 6 platform.
Why was the darwin 6 platform removed? Do you have knowledge that it does not function anymore, or is not necessary anymore on darwin 6? Unless you do, darwin 6 platforms should be left in place. The latest consensus on darwin 6 was that although it is no longer a supported platform, we would still accept patches to fix things for darwin 6, and we should not deliberately break darwin 6. At least that's what I recall. If we want to change that policy now, then let's discuss that (and document the outcome in the guide of course).
I thought unsupported things should be removed from portfiles. Out of curiosity, does base still build on darwin 6?
Unless we know for sure that it doesn't work, we should leave the support in there.
This is the previous thread I was thinking about, in which I specifically asked what we should do about Jaguar support: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001921.html Daniel Luke said we shouldn't be opposed to accepting patches to make broken things work on Jaguar; that means we also shouldn't deliberately break Jaguar support: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001923.html Eric Hall said we shouldn't take actions to make life more difficult for Jaguar users: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001988.html I requested that this be documented: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001993.html Blair Zajac was strongly in favor of retaining support for Jaguar systems: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001995.html Boey Maun Suang was also in favor of leaving Jaguar code in: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001997.html Those were all the messages in the thread. Nobody voiced an opinion against retaining the existing Jaguar support. I don't really care one way or another. I just want there to be a documented policy. If the policy is "keep Jaguar stuff", then let's keep it. If the policy is "get rid of Jaguar stuff", then let's get rid of it all right now.
On Sep 8, 2007, at 23:39, N_Ox wrote:
Le 8 sept. 07 à 22:04, Ryan Schmidt a écrit :
On Sep 8, 2007, at 08:58, source_changes@macosforge.org wrote:
Revision: 28760 http://trac.macosforge.org/projects/macports/changeset/ 28760 Author: nox@macports.org Date: 2007-09-08 06:58:45 -0700 (Sat, 08 Sep 2007)
Log Message: ----------- libtool: * Added standard doc install.
Please don't forget to increment the port revision when you make a change that causes the port to install different files. I've been fixing this on the ones you've just committed.
From what I've understood until now, documentation files is not relevant enough to increase revision number. Nevertheless, it would not hurt that much to increase it and i have never done it because i thought that was the current policy, thanks again for noticing me it's not.
I feel that if the complement of files that gets installed by port is different, the revision number needs to be increased (unless the version increases, and then the revision needs to be deleted or dropped to 0). I think that's pretty simple and easy to remember, so that's what I recommend. We should document this in the guide. If anybody objects to this policy, let's please discuss it now. The goal is for everybody who installs a port to get the same software. It's confusing if some people who install libtool-1.5.24_0 get one thing and other people who install libtool-1.5.24_0 get something different. Perhaps documentation files are minor. Perhaps not. Either way, I think we want people who are submitting bugs, for example, to be able to do so unambiguously against a particular port version and revision. What if the bug is about the documentation? What if someone has libtool-1.5.24_0 installed and notices that there is no documentation, and submits a bug "libtool-1.5.24_0 should install documentation"? It seems natural to respond "I updated the port to install the documentation, and 'port outdated' will soon show it, and you can then update to it." It seems weird to say "I updated the port to install the documentation, but I'm not incrementing the revision, so the only way to obtain the documentation is to either know that I did this and force an upgrade, or hope that libtool will be updated to a new version soon so that you get the documentation then." It also simplifies answering questions. "Do I have the libtool documentation?" It's nice to be able to answer "Do you have 1.5.24_1 or later? Then yes. Otherwise no." It's not so nice to have to answer "Do you have 1.5.24_1 or later? Then yes. Do you have 1.5.22_0 or earlier? Then no. Do you have 1.5.24_0? Ok, when did you install it? If before September 8, then no. If after, then yes."
participants (3)
-
Blair Zajac
-
N_Ox
-
Ryan Schmidt