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

[Mamoru Tasaka]

Jindrich Novy wrote, at 01/05/2008 05:54 PM +9:00:
> 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.

Well, it can be that one (huge) tarball has several sub-components which
are developed independency and they has different versions _internally_
however they are released in one tarball anyway?

Generally if one component of the tarball is updated (for example
xdvi is updated from 22.84.12 to 22.84.13), then upstream should also bump the
version of the tarball because even if only one component of the (huge)
tarball is changed it means from external it means that the tarball is changed
anyway (i.e. texlive must have version "2007.1", for example).
If upstream releases new version of the tarball without changing the version
but with changing one of the components, it is very confusing and in the case
"we" (rpm packager) should change version intentionally (like ImageMagick).

IMO "version" of rpm should respect from what "tarball" the rpm is generated.
For xdvi if providing "22.84.12" is preferable, it must be treated by
vertial provides, i.e. the name of rpm should be "texlive-xdvi" with version
"2007", with providing "xdvi = 22.84.12".

 
Mamoru