[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
> 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. 

It hurts in the eyes ;-)

> o it will enable the cousing fedoralegacy to have clean backbuilds.

I'm not sure if I understand you correctly (what is "cousing"?), but you
can simply do the obvious and append the release to the existing one,
like in:

last rel: "3", next rel: "3.1"

or for the sake of being talkative to users maybe even:

last rel: "3", next rel: "3.fc1.1"

despite that being ugly to the eye. But we would have to support FC1
only for a short time after FC2 is out, don't we? In that case, even I
can live with a certain amount of ugliness.

> o it will enable Red Hat to have decent common errata for multiple
>   non-EOLed releases.

How do we not have that today?

> 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.

As long as either the release itself or one component is an integer,
bumping that is easy. In fact it works today, ask Elliot -- I don't
think he fiddles manually with hundreds of release tags when doing a

> 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.

I think we're talking about Fedora Core and 3rd party repos, let's make
that distinction even if Fedora Core development is largely staffed with
Red Hat people today. My impression is that Fedora Core objectives in
this issue are to work inside of Core/Extras/Alternatives however these
are defined, anything beyond is "out of scope". That's my personal

> o there will be no more big threads about disttags w/o a resolution :)

Haha. On the other hand, we could all just shut up ;-).

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

Obviously you are joking, but then you haven't seen our build system
yet, have you?

> 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.

In my point of view, disttags serve only one purpose, namely
differentiating from which repository a package comes in the file name,
at the price of looking ugly. They do not improve interoperability a bit
because the package manager wouldn't know that if package "foo" from
repo "bar" needs "baz" then it must come from "bar" as well or at least
from "stfu" ;-). Using disttags doesn't make upgrading package "xyz"
from the external repo "abc" to the one in Core easier unless both sides
plan in that regard.

If I were to "usurp" a package for Core, I would only want to ensure
upgradability for that package eventually existing in Extras, for which
simple integers as releases suffice, mind my words (incrementing them is
an easy operation ;-) or alternatively for the package from another repo
I based off. I would not try to be "later" v-r-wise than any other
instance of the package in one of your, Dag's or any other of the
myriads of repositories because things would then simply be getting out
of hand.

     Nils Philippsen    /    Red Hat    /    nphilipp redhat com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]