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
Attachment:
pgpTzbN1fBd2U.pgp
Description: PGP signature
