[Fedora-packaging] Re: release of subpackage with version different from main rpm

[Axel Thimm]

On Sat, Jan 05, 2008 at 09:54:30AM +0100, Jindrich Novy wrote:
> On Wed, Jan 02, 2008 at 09:08:44AM -0600, Rex Dieter wrote:
> > Mamoru Tasaka wrote:
> > 
> > > I guess there are some packages of which subpackage rpms have versions 
> > > which are different from those of the main rpm.
> > > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage
> > > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR.
> > > 
> > > On such case are there any policy for release number? For perl currently
> > > the main perl rpm and its subpackages have the same release number.
> > > However in other rpms the case may happen that only the version of 
> > > main rpm will be bumped where the version of its subpackage won't change.
> > > In that case usually we want to switch the release number of main rpm
> > > to 1%{?dist}, however if its subpackage has different version the release
> > > number of the subpackage usually can't be back to 1%{?dist}. How should
> > > we treat this case?
> > 
> > imo, the simplest solutions for cases like this are:
> > 1.  don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR
> > 2. where different Versions are desired, make these a *completely
> > separate* pkg, not just a sub-pkg.
> 
> None of these approaches are possible in some cases, say TeXLive. The
> distribution consists of many independent parts, but as a distribution it has
> one huge tarball. Following your suggestion would lead to have a couple of
> separate packages containing full tarball from which only a particular
> part which is packaged is ripped off, which is quite wasteful IMO.
> 
> In case of one package and many subpackages, the "subpkg EVR = main pkg EVR" is
> also not possible, because each bit has a different version, because
> they are developed independently.
> 
> Why to strictly avoid subpackages with a different NEVR than the main one? I can
> imagine many of situations where it makes perfectly sense, the one I
> described is one of these.

texlive is a special case, there are not that many
in-between-upstreams that do a collection of other projects.

In general it is desirable to have one-tarball-one-specfile-one-
version setups. For texlive it would have meant to split up texlive
into its components and retarball them (or persuade upstream to do
so).

Since using texlive means relying on an in between upstream to do the
intergration work the above is nonsense, of course, so keep on the
subpackaging versioning as you do.

But other than texlive or maybe even the kernel (with many subsystems
having their own version) I don't think this applies to many other
examples, so we can special-case texlive and have otherwise a general
rule of thumb that "using different evr in subpackages is an
indication of something wrong".

Just as an example about the wrong setup: Look at how often rpm/popt
packages broke in their upgrade path in the past for having two
versions in a tarball - thank god we have finally two sources for them.
-- 
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://listman.redhat.com/archives/fedora-packaging/attachments/20080105/15b15e29/attachment.sig>