On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)

[Axel Thimm]

On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
> On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
> > The packaging guidelines are useful for such private repos as well,
> > such that private packages.  And if it's good for private repos in
> > the sense of getting a clear upgrade path, it's good for public
> > repos in the this sense as well.
> 
> And consequently good for Red Hat's own packages themselves. ;)
> [...]
> So will FC3 has disttags? :)

On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
> Frankly, I don't see the point of disttags for the core packages.  The
> only purpose of disttags IMHO is to differentiate builds of the very
> same package for different OSs/releases.  Fedora Core packages never
> use this; if there's a rebuild for the next release of Fedora Core,
> the build number is incremented.  If there's an errata-like patch
> build for an update for an earlier release, it can get a .1 suffix
> to the released build number, for the first such build, and have this
> suffix incremented for subsequent builds.  So, when are they useful
> for packages in the Core?

o for first it will certainly not hurt at all. 
o it will enable the cousing fedoralegacy to have clean backbuilds.
o it will enable Red Hat to have decent common errata for multiple
  non-EOLed releases.
o it will enable rawhide to have good upgrade paths for unchanged
  packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
  packages for test2.
o it will provide a coherent specification for Red Hat and third party
  repos to use. Asking of repos to change/apply vereioning specs w/o
  Red Hat to follow is not going to work.
o there will be no more big threads about disttags w/o a resolution :)

The downside is that someone must spent a day and a half to get the
build system at Red Hat to add disttags.

Disttags are a good concept. The only thing hindering them in the
Fedora/RHEL world is the choice for a specific implementation. If the
vendor does not go along, you will continue to have anarchy in
guidelines.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040514/d3e90130/attachment-0002.bin