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

[Axel Thimm]

On Tue, May 11, 2004 at 10:11:42PM -1000, Warren Togami wrote:
> Ralf Corsepius wrote:
> >I am planing to release a couple of rpms which are supposed to be add-on
> >packages to Fedora Core and/or Fedora Extras.
> >
> >What is the current convention on choosing rpm release tags for such
> >packages to provide co-existence for such kind of packages?
> >
> >AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
> >such kind of convention.

We tried to discuss this here, but there wasn't much interest from Red
Hat's side, as Red Hat is always focusing on the latest release and
resolves concurrent builds for different distros (whenever they
happen) on an as needed basis (so each time the solution is different,
sometimes without a tag, sometimes with a tag like "FC1" and so on).

The main idea is to have a scheme that does not apply to the scope of
this one distribution and this current time window. It should apply on
FC, RHL, RHEL and why not Mandrake/SuSE, whatever.

So the general stance is to have a suffux to the release tag
containing an rpm-sortable disttag and an optional repotag, like

foo-1.2.3-4.rh9.ralf.src.rpm

So the release tag looks like

   <buildid><distid><distversion><repotag_opt>

where buildid shound end with digits (for example a simple integer
like "3", or something conatining cvs info like "0.cvs20040512.16"),
distid should be invariant for the family of distributions and
distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
is placed at the least significant place wrt to rpm comparison and is
optional.

Nobody objected this scheme above, but the implementation was
difficult, given the constraint, that FC should be considered as a
successor to RHL in rpm upgrade path terms. So the disttag to FC
needed to be rpm-higher than that of RHL.

A solution used by currently most free repos is to have "rh" for RHL
and "rhfc" for FC. It works very well, but some (Warren ;) disliked
the association with rh in FC rpms and decided to find another
solution. Current rpm (2003 upwards) sort digits above letters, so
a trick/kludge is used in fedora.us' convention to ensure
upgradability, the distid in the scheme above is completely dropped.

There is no perfect scheme, and you need to choose for yourself. I
wished there would ba a scheme that would allow for 

       foo-1.2.3-4.fc1.ralf.src.rpm

without breaking too much the schemes for RH9 downwards. A suggestion
that was dropped here and died in silence, was to use fc0.9 for rh9 to
make it fit into this scheme, e.g. declaring RHL as a 0-dot
predecessor to FC. But again that was politicaly non-correct. :(

Anyway, RHx are all past EOL and perhaps it is time to consider a
scheme that is clan for FC ("fc1", "fc2", ...) and obfuscates RHL
releases. Anything that is rpm-smaller than "fc", e.g. let it start
with a-e, or maybe indeed the "fc0." distid for RHL.

> >Conversely, all seem to be designed "to take over the system".

Even though this is our secret obsession, what do you man by that? 

> I assume you mean by "taking over the system" you mean replacing 
> packages that are within the core distribution?  fedora.us and livna 
> does not do that at all.  The other 3rd party repositories are 
> controlled by single persons and they generally do whatever they want 
> unilaterally, for better or worse.

I am sure for better, but I am biased :)

It is funny that the single-person-controlls-all was the main argument
for the free repos leaving fedora.us last year ...

FWIW AFAIK all free repos accept submissions of packages and also help
you in setting up your repo, if that is what you want to do.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040512/445cc3d1/attachment-0002.bin