release of subpackage with version different from main rpm
 

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

release of subpackage with version different from main rpm
 

Mamoru Tasaka wrote:


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?


*cough* kde *cough*. :)

-- Rex

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

release of subpackage with version different from main rpm
 

Rex Dieter wrote, at 01/05/2008 10:17 PM +9:00:

Mamoru Tasaka wrote:


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?


*cough* kde *cough*. :)

-- Rex


I must say that kde packaging is very confusing...

Mamoru

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

release of subpackage with version different from main rpm
 

On 01/05/2008 Mamoru Tasaka wrote:
> 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?

Perl does this too. :/

~spot

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

release of subpackage with version different from main rpm
 

>>>>> "TC" == Tom "spot" Callaway <Tom> writes:

TC> Perl does this too. :/

And it causes pain, as we all know.

The problem is that we're a distribution, packaging up another
distribution. I guess we could bypass texlive altogether and just
pull in all of the various upstreams ourselves, but of course that
would require a hideous amount of maintainer time.

If there's a component (of texlive, Perl, or whatever distro we're
repackaging) which we frequently feel like we need to update out of
sync with the distro that packages it, we shouldn't hesitate to
package it separately.

- J<

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

release of subpackage with version different from main rpm
 

On 01/05/2008 Jason L Tibbitts III wrote:
> If there's a component (of texlive, Perl, or whatever distro we're
> repackaging) which we frequently feel like we need to update out of
> sync with the distro that packages it, we shouldn't hesitate to
> package it separately.

Well, yes and no. This is a place where I've got to assume that upstream
has a good reason for bundling these components together in the same
tarball. If one of those bundled components frequently needs updates, we
should be having dialogs with upstream about:

A. Whether that component needs to be bundled in
B. Whether the supertarball needs to be updated more often
C. What the effect of Fedora updating the component will be on the
supportability of the whole, from an upstream perspective

With that data, when needed and with upstream support, we shouldn't shy
away from packaging it separately.

~spot

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