Re: release of subpackage with version different from main rpm

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

 



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

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux