Date: Wed, 25 Mar 2009 18:46:47 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org>, obrien@FreeBSD.org Cc: cvs-ports@FreeBSD.org, Pav Lucistnik <pav@FreeBSD.org>, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/shells/bash Makefile pkg-plist Message-ID: <p06240801c5f05e63fc0f@[128.113.24.47]> In-Reply-To: <49C842CB.6070900@FreeBSD.org> References: <200903120954.n2C9s2ev063133@repoman.freebsd.org> <20090313023956.GA49511@dragon.NUXI.org> <49BA52D2.8090209@FreeBSD.org> <20090323231412.GA94221@hub.freebsd.org> <49C842CB.6070900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:17 PM -0700 3/23/09, Doug Barton wrote:
>David O'Brien wrote:
> >
> > If not, maybe we should do away with PORTREVISION and use
> > something like:
> >
>> ${PORTNAME}-${PORTVERSION}_${VCS_ID}
>
>I actually have in mind a different scheme that replaces both
>PORTREVISION and PORTEPOCH with a date string like 200903231 that
>would be appended to each PKGNAME. It would completely remove the
>ambiguity (and the kludgy mess that both of the current variables
>have created), and has the extra added bonus that you could set it
>differently depending on which options the user has set without
>fear of creating ambiguity. But I digress ...
Somewhere I suggested an idea of a separate version-id value which
would be for the "version in the ports collection" itself, and put
that before the "version as taken from the package".
So, the original bash project might release a version as 3.2.48.
If a new version of the freebsd-port for bash was created on
March 25th, then my suggested value for "ports-version" would be
2009C25a (2009, "C" = march, 25th, "a" = "first one of that day").
Thus the combined version-string would be:
bash_2009C25a-3.2.48
new versions of any port would never go backwards, alphabetically,
so there's no need for a "PORT_EPOCH".
Another advantage is that it becomes trivial to see if the bash
port has been modified at all since some other port (say, "gcc")
was updated. Well, trivial, unless they did happen to be updated
the same day.
There are more details to the timestamp that I'm suggesting, but
that's basically it. I've used this timestamping-method for
various files I create for various purposes here at RPI, and it
seems to work out without introducing any particular problems.
--
Garance Alistair Drosehn = drosehn@rpi.edu
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06240801c5f05e63fc0f>