On Wed, 2008-03-05 at 09:34 -0900, Jeff Spaleta wrote:
On Wed, Mar 5, 2008 at 9:28 AM, Colin Walters
<walters(a)redhat.com> wrote:
> The overall idea is that the release number is determined by the "build
> server", where "build server" can be either localhost (for make
local),
> or Koji (for Fedora). So for local builds, you don't hit Koji to
> determine a release - we just create one, and then increment it from
> there.
>
> We don't want to distribute locally-built RPMs as if they came from
> Fedora, so giving them a .local disttag with a locally-determined
> release is a good thing, I think.
I think you have to abstract this a little and rely on a increment
counter macro in the release field to give maintainers the option of
using(or not) and potentially overriding. That way maintainers can
encode the integer counter into the Release field in a way that makes
sense to keep the update path working...even for wacky 'edge' cases
like the kernel.
My thought on this is that you can only switch to the new system after a
new upstream release. That avoids the issue of backwards compatibility
mappings, because the new upstream version will override any previous
Release tags.
I don't know what's special about the kernel - can someone needs to
explain to me what need it has that wouldn't be met by this system?