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

[Ralf Corsepius]

On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> > 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
> 
> I thought there was some minor opposition.  <buildid> should *always*
> start with `0.', such that, whenever the distro contains the same
> version of the package, starting with 1 or above, the version in the
> distro is used.  If you build multiple times, use 0.1, 0.2, etc.
> 
> My actual preference would be to instead use:
> 
>      0.<distid><distversion><repotag_opt><buildid>
> 
> >> >Conversely, all seem to be designed "to take over the system".
> 
> > Even though this is our secret obsession, what do you man by that? 
> 
> Dunno what he meant,

I meant external repositories having chosen their release tags in such
way, that they can not be upgraded to original RH or Fedora.US packages.

For example: Consider a package now being shipped by livna for legal
issues: xxx-0.lvn.1.1.i386.rpm

Now suppose, the legal situation changes and the package shall be moved
to Fedora.US: xxx-0.fdr.2.i386.rpm

# rpmver 0.fdr.2.1 0.lvn.1.1
0.lvn.1.1 is newer

=> Can't get rid of this lvn rpm by using Fedora.US PackageGuideLine
conforming release tags, once you have installed it.


The same applies to other 3rd parties.

Another example: Axel ships perl-XML-Writer-0.4.6-7.rhfc1.at for FC1.

Now suppose, RH had chosen to ship perl-XML-Writer-0.4.6-1 with FC2
# rpmver 0.4.6-7.rhfc1.at 0.4.6-1
0.4.6-7.rhfc1.at is newer

=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this
FC2 package without Axel having any possibility to do anything about it.

Now consider my situation: In general, I want have a clean Fedora Core +
Fedora Extras installation, but want to install packages which
_currently_ are not part of Fedora Core1 nor Fedora Extra.
Some of them (like the perl-XML-LibXML-Common rpm I had mentioned) are
known to be part of FC2, others are likely to be part of future FC/FE
release, others will probably be shipped by 3rd parties.

ATM, however I have to resort to locally built or non-FC/FE rpms, but do
want to keep the possibility of FC and FE packages to replace my local
packages during updates/upgrades.

>  but IMHO external repositories should be split
> into Extras and Alternatives, where Extras contain packages that add
> to the system without replacing any of its core components, leaving
> replacing/upgrading to Alternatives.

I am still missing an official RH or Fedora.US guide line.

What I see from experimenting with release tags yesterday, there
implicitly exists such a convention:

<fc-release>.fdr.<fdr-release>.<local-vendor-id>.<local-release>.<disttag>

with:
<fc-release> .. RH/FC package release number this package is supposed to
be replace. 0 for Extras, equal to the RH/FC release number for
Alternatives.
<fdr-release> ... Fedora.US release number this package is supposed to
replace. 0 if neither FC nor FE has this package. equal to FE's release
number if FE has the packages.
<local-vendor-id> ... an arbitrary string starting with a non-numeric
character.
<local-release> ... "Local Vendor's" actual build-number
<disttag>  ... Fedora US's disttag.

Some of the dots might be optional but didn't look into them (I like them :-) )

Ralf