Re: [114136] trunk/dports/databases/postgis2/Portfile
On Nov 30, 2013, at 11:47 PM, Vincent Habchi vi...@macports.org wrote: Blair: That’s right, they can never be removed. Thanks. By the way, what was the ‘epoch’ meant for, initially? Epoch is incremented when you need to decrease the port’s version number, otherwise there’s no way to upgrade the port when the upstream release version number decreases. Say package foo is at 2.0 and the upgrade to 2.5 breaks everything, then you need to back down to 2.0, but without an epoch number, there’s no way to do that and to have MacPorts see that it needs to “upgrade” from 2.5 to 2.0. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
The epoch line is no more a wart than any other line of the Portfile… it’s just a syntax for accomplishing a task. On Dec 1, 2013, at 01:47, Vincent Habchi wrote: Blair: That’s right, they can never be removed. Thanks. By the way, what was the ‘epoch’ meant for, initially? You mean in this port? or generally? In general, port versions increase. 1.0 is followed by 1.0.1 is followed by 1.1 is followed by 2.0. However sometimes version numbers change in such a way that they appear, based on the normal rules, to decrease. For example, if a project does not assign version numbers, the port maintainer may have invented a version number that looks like a date, such as “20090103”. This is fine until a real version of the software is released, such as “1.0”. When that happens, version “20090103” will appear to the normal MacPorts version comparison procedure (vercmp) to be greater than “1.0” though it should in fact be considered to be less. That is the time when you increase the epoch from its default “0” to a higher number, such as “1”. “port outdated” shows you ports MacPorts thinks are outdated. That list includes ports whose versions are greater (i.e. upgrade 1.0_0 to 1.1_0), those whose versions are the same and whose revisions are greater (i.e. upgrade 1.0_0 to 1.0_1), and those whose epoch is greater (i.e. 20090103_0 (epoch 0) to 1.0_0 (epoch 1)). You added the epoch line to this port in r95593 when you updated the port from version “2.0.1-svn” to version “2.0.1”; without this, MacPorts would not have known that “2.0.1” should be considered to be greater than “2.0.1-svn” and this update would not have been displayed to users in “port outdated”. If you are unsure how vercmp will behave for any given versions, you can test it out by using the vercmp script in my users directory: $ ~/macports/users/ryandesign/scripts/vercmp 2.0.1-svn 2.0.1 MacPorts considers 2.0.1-svn to be greater than 2.0.1. Now that the epoch line is in this port, it can never be removed or decreased, otherwise MacPorts will not show any future updates to users in “port outdated”. This is not a problem. This is the situation the “epoch” keyword was designed to address. It should not be our goal to avoid using the epoch keyword; it should be our goal to understand how the epoch keyword works and to use it for its intended purpose such that users can be told the true version of the software that they are installing, not a made-up version number the maintainer invented to avoid using the epoch keyword. To complete the trio, the revision keyword is intended for situations where the maintainer wishes to change the files the port installs without changing the version of the software that is installed. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
The epoch line is no more a wart than any other line of the Portfile… it’s just a syntax for accomplishing a task. […] Thanks Blair Ryan for the explanation. I just wish there would be some other mechanism somehow able to tweak the ‘update detection’ script. E.g, considering that any X.Y.Z version is actually newer than X.Y.Z-…; more precisely, that any trailing hyphen indicates a development version. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
On Dec 1, 2013, at 03:25, Vincent Habchi wrote: The epoch line is no more a wart than any other line of the Portfile… it’s just a syntax for accomplishing a task. […] Thanks Blair Ryan for the explanation. I just wish there would be some other mechanism somehow able to tweak the ‘update detection’ script. E.g, considering that any X.Y.Z version is actually newer than X.Y.Z-…; more precisely, that any trailing hyphen indicates a development version. That’s not always the case. For example, libtcd was updated from 2.2.5 to 2.2.5-r3 in r114005. 2.2.5-r3 is not a development or alpha or beta or release candidate version; it’s the third actual release of the stable version 2.2.5; it comes after 2.2.5. It’s possible we could make vercmp smarter. But I would want to be careful that we don’t break any existing upgrades in the process. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
Le 1 déc. 2013 à 10:44, Ryan Schmidt ryandes...@macports.org a écrit : That’s not always the case. For example, libtcd was updated from 2.2.5 to 2.2.5-r3 in r114005. 2.2.5-r3 is not a development or alpha or beta or release candidate version; it’s the third actual release of the stable version 2.2.5; it comes after 2.2.5. Could it have been coded 2.2.5.3 instead? It’s possible we could make vercmp smarter. But I would want to be careful that we don’t break any existing upgrades in the process. Maybe we could add a ‘sub-version’ or ‘dev-version’ tag, that, when set, would indicate that the release is not final; between two Portfiles with such tags, the one with the ‘highest’ one would win. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
On Dec 1, 2013, at 04:14, Vincent Habchi wrote: Le 1 déc. 2013 à 10:44, Ryan Schmidt a écrit : That’s not always the case. For example, libtcd was updated from 2.2.5 to 2.2.5-r3 in r114005. 2.2.5-r3 is not a development or alpha or beta or release candidate version; it’s the third actual release of the stable version 2.2.5; it comes after 2.2.5. Could it have been coded 2.2.5.3 instead? It’s not version 2.2.5.3; it’s 2.2.5-r3. That’s what the developers call it. If we were to call it 2.2.5.3, and the user told the developer (in a bug report, say) that they were using version 2.2.5.3, the developer would be rightly confused, since he has never released any such version. We should not confuse users and developers. We should call things what they are. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
Le 2 déc. 2013 à 04:22, Ryan Schmidt ryandes...@macports.org a écrit : We should not confuse users and developers. We should call things what they are. I concur with you. We’re computer scientists, not politicians :) Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
On Nov 30, 2013, at 02:58, vi...@macports.org wrote: Revision 114136 Author vi...@macports.org Date 2013-11-30 00:58:54 -0800 (Sat, 30 Nov 2013) Log Message Bump to v 2.1.1. Following Sfcgal update to 1.0.4, the option +sfcgal is again active. Modified Paths • trunk/dports/databases/postgis2/Portfile Diff Modified: trunk/dports/databases/postgis2/Portfile (114135 = 114136) --- trunk/dports/databases/postgis2/Portfile 2013-11-30 08:45:29 UTC (rev 114135) +++ trunk/dports/databases/postgis2/Portfile 2013-11-30 08:58:54 UTC (rev 114136) @@ -7,8 +7,7 @@ namepostgis2 categories databases gis license GPL -epoch 1 -version 2.1.0 +version 2.1.1 The epoch may never be removed or decreased; please put it back. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
Hi Ryan, The epoch may never be removed or decreased; please put it back. Done in r114183. Does that mean that we can’t never get rid of that epoch wart? Cheers! Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
On Nov 30, 2013, at 11:41 PM, Vincent Habchi vi...@macports.org wrote: Hi Ryan, The epoch may never be removed or decreased; please put it back. Done in r114183. Does that mean that we can’t never get rid of that epoch wart? That’s right, they can never be removed. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114136] trunk/dports/databases/postgis2/Portfile
Blair: That’s right, they can never be removed. Thanks. By the way, what was the ‘epoch’ meant for, initially? Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
