On Mon, 2004-05-17 at 20:26, Axel Thimm wrote:
> On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
> > On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
> > > On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
> > > > 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!).
> > >
> > > Not in my opinion.
>
> > Neither in mine. IMO, what some people on this thread call "disttag"
> > actually is the "root distribution's" repotag. What is confusing is
> > the fact that RH/FC doesn't use an explicit "RH-repotag/disttag",
> > while 3rd party packagers apply different and partially
> > contradicting "disttag" conventions.
>
> No, please don't add to this confusion by defining disttags to be
> repotags of some kind.
>
> For simplicity's sake forget about repotag, their current
> usage/existance etc. The repotag serves no real technical
> functionality.
To reiterate: I think distinguishing between "disttags" and
"repotags" is meaningless, it's all about repotags, only.
In my understanding "disttags" actually are a special case of repotags:
The repotag of the "root" of the repository hierarchy your packages are
using.
> The disttag OTOH is the tools for automatically maintaining upgrade
> paths even when building from the same specfile into multiple
> different distributions.
This does not contradict to what I wrote above.
> You achive this by either carefully choosing release tags (say "3" for
> FC1, "4" for FC2) which leads to different specfiles/src.rpm etc., and
> non-predictable release tags ("which one fixed the xyz issue? Release
> 3 or 4?").
>
> Or you pick the same release tag (for example "3") and add a different
> suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
> and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
> and you know that the true buildid is the "3" which can be used in
> ranged dependencies (Requires: foo >= 1.2-3). And the upgrade paths
> are always pertained.
OK, an example of how I see it:
Consider you are building add-on packages to Fedora Core N
Dependency tree:
FCN -> AddOns
Fedora Core N repotag: fcN.
Add On repotag: AddOn.
A convention on release tags could be: <repotag><number>
This would result into a release tag similar to this:
fcN.<fcN-id>.AddOn.<AddOn-id>
What might confuse you is me regarding "fcN" as "repotag" and not "fc"
as you seem to be seeing it.
Another part of confusion might stem from RH/FC currently not using any
repotag/disttag (which could be interpreted as "empty") and Fedora.US
trying to add one.
Ralf
