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