On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)
Axel.Thimm at ATrpms.net
Fri May 14 09:07:09 UTC 2004
On Fri, May 14, 2004 at 10:42:18AM +0200, Nils Philippsen wrote:
> On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
> > o it will enable the cousing fedoralegacy to have clean backbuilds.
> I'm not sure if I understand you correctly (what is "cousing"?),
sorry, that's a typo it's "cousin".
> 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"
But these _are_ disttags! :)
> > o it will enable Red Hat to have decent common errata for multiple
> > non-EOLed releases.
> How do we not have that today?
Don't ask me, have a look at the differnt (read per package) solutions
used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc,
ethereal). Some packages got a ".7", ".8", ".9" appended, others an
"FC1" etc, even others simply enumerated them.
If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and
foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and
FC2, w/o reinventing the wheel each time.
> > 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
No, that would be suicide, but the bumbed Release tag is not helpful
for investigating what has changed. Sometime the %changelog is
helpful, other times one need to open the packages and compare
content. A changing disttag with otherwise invariant buildid doesn't
even need a changelog about rebuilding.
> > 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
Well, the thread started about someone wanting to provide packages for
third party repos or Extras with disttags. If you look at fedora.us,
which is deemed ti become Fedora Extras, you will see disttags. Are
you suggesting to remove them? fedora.us developers would not be happy
> > 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?
Of course, I am joking. OTOH there are existing buildsystems in
various projects including ATrpms, fedora.us, Dag and probably more
that have solved this a long time since. So it is not really rocket
science, once a disttag scheme has been approved. Perhaps you should
hire me ;)
> > 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.
Oops, I understand that we are probably talking about different
things. What you are thinking of are "repotags" like "fr", "at",
"dag", "ccrma", "spc", "dries" that only serve for uglyness and have
no functionality. I am not promoting their use, they shoudl be
considered optional and should stay out of our way (in an upgrade
path consideration, e.g. shove them at the very end of the release tag
if you really must so).
> 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, [...]
You should think outside of the Fedora Core scope where disttags are
indeed only useful for common errata with simultaneous non-EOLed
Projects very near to Fedora Core (not "3rd party") like Fedora Extras
predecessor fedora.us, and fedoralegacy.org do require more often to
have common builds differentiating in the release built against. So
disttags are required.
And as a community project you cannot keep out of scope "3rd party"
repos. They also support multiple releases of Red Hat and Fedora and
ths need disttags (not repotags!).
And really, disttags do not hurt at all. Aesthetics don't count in
packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040514/c8a3d8a6/attachment-0002.bin
More information about the devel