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 > mass-rebuild. 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 > opinion. 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 about that. > > 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 releases. 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 setup.exe. -- Axel.Thimm at ATrpms.net
Attachment:
pgpIHMOLovlg8.pgp
Description: PGP signature
