On Wed, 2008-03-05 at 09:34 -0900, Jeff Spaleta wrote: > On Wed, Mar 5, 2008 at 9:28 AM, Colin Walters <walters@xxxxxxxxxx> 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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
