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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2004-05-12 at 16:56, Axel Thimm wrote:
> On Wed, May 12, 2004 at 03:44:53PM +0200, Ralf Corsepius wrote:
> > > 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.
> > In an ideal world, yes. 
> > 
> > But I have given in hope vendors can agree on a common naming scheme
> 
> Why? It hasn't even been proposed/tried, yet. And it is too early to
> propose it, but it can be taken account for to not blcok this path.
> 
> > > 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
> > 
> > AFAICT, this approach considers upgrades between distros, but it does
> > not consider replacing RH supplied Core packages or nor replacing
> > Fedora.US supplied packages nor does it consider replacing "local
> > packages" with Fedora.US supplied packages.
> 
> I am not sure, what this means. The repotag can be used as an
> indicator about which packages in your system come from where (there
> are other ways apart from versioning/naming to achieve this).
Exactly.

> If a repo choses to replace some part of the base distribution for
> some reason, it is in the responsibility of the repo to do so in a way
> as to not break anything and ensure future upgrade paths either by
> hierarchical build tags for automatically being replaced by newer
> vendor releases, or commitment to a community SLA.
Exactly, that's what I am trying to achieve.

> > > A solution used by currently most free repos is to have "rh" for RHL
> > > and "rhfc" for FC.
> > Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have
> > switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1
> > rpms there yet, but I am involved there) uses '<vendor-release>.pm', ...
> > finally there are Ximian and JPackage ... and ...
> 
> most != all ;)
> Other than ATrpms rhfc1 is currently used by DAG, PlanetCCRMA, spc,
> dries, biorpms, and probably more.
OK, ok, ... :-)

> > * FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
> > * Thereofore I'd expect a potential FC1-Extras/Legacy package to be
> > named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
> > 
> > Now, which release-tag to use for my "temporary legacy package"?
> > 
> > As it seems to me, the only functional solution for my purposes is:
> > perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
> > 
> > For example:
> > perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
> 
> Is this a simple backport?
It's even simpler: It is just a rebuilt FC2 package.

I.e. it would make the "classical case" of a Fedora.US Legacy package.

Michael's remark "sign Ville's proposal" however, makes me wonder if Red
Hat and Fedora.US actually have an official policy on such packages.

His remark makes doubt it :(

> BTW that package already exists:
> # apt-cache policy perl-XML-LibXML-Common
> perl-XML-LibXML-Common:
>   Installed: (none)
>   Candidate: 0.13-2.rhfc1.dag
>   Version Table:
>      0.13-2.rhfc1.dag 0
>         995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
>      0.13-1.rhfc1.dag 0
>         995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
I am well aware perl-XML-LibXML-Common exists at various places (Even I
have a local one), but ... it now is part of FC2 and there exists a
proposal for Fedora.US/FC1 ...

Ralf





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux