On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
On May 12, 2004, Axel Thimm <Axel.Thimm(a)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