Date: Fri, 08 Jul 2005 20:39:42 -0700 From: Ade Lovett <ade@FreeBSD.org> To: Michael Nottebrock <lofi@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: PORTEPOCH (was Re: lang/gcc33: snapshots -> final release) Message-ID: <42CF46FE.2050304@FreeBSD.org> In-Reply-To: <200507090145.00506.lofi@freebsd.org> References: <Pine.BSF.4.62.0507082349240.14905@pulcherrima.dbai.tuwien.ac.at> <Pine.BSF.4.62.0507090003340.14905@pulcherrima.dbai.tuwien.ac.at> <1120861640.91809.15.camel@hood.oook.cz> <200507090145.00506.lofi@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Nottebrock wrote: > I really wonder why everybody is so afraid of PORTEPOCH and tries to work > around it Well, from my perspective, PORTEPOCH is something of a kludge in that once created, it can never be removed, only increased whenever there's an "oops" of any kind with the versioning of the port (mainly down to less than stellar version handling by the actual source, though this particular case is somewhat different). The number of ports with the ugly (to my mind) ",<number>" at the end can only therefore ever increase, so that character string is somehow a nagging sensation in the back of my head about such mistakes. Compare PORTEPOCH with PORTREVISION for example, when extra patches or other circumstances require a minor bump for port dependency chaining, but without actually having a new distfile. As and when a newer version of the relevant source becomes available, PORTREVISION is removed (or set to 0), and the extra "_<number>" tag vanishes into dim and distant memory. It's certainly an issue of perception, rather than a solid, valid, technical argument against it, though the irreversibility of PORTEPOCH is something that is less than desirable. And no, I don't have a solution. Still trying to write up an automated patch bot to sweep the tree for impending USE_AUTOTOOLS conversion after 6.0-RELEASE is out the door :) -aDe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42CF46FE.2050304>