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

[Axel Thimm]

On Sat, Jan 05, 2008 at 07:30:46PM -0500, Tom spot Callaway wrote:
>  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. 
I guess the question is whether to keep it technically possible to
perform such updates. If you have a supertarball and use for all
subpackages a common evr, even one that doesn't match the real
upstream's subpackages' versioning, then for updating one subpackage
you need to update them all, or you would have to package an external
package or upstream foo using a false version, e.g. adapting a version
scheme like the superpackage's. And you would run into evr races with
the supertarball.

So it boils down to either total commitment to the intermediate
upstream's updating and versioning or keeping separate versioning
matching the true upstream thus allowing to deviate from the
intermediate upstream. All in all it's about the future freedom of
choice.

And given that tex distributions even very stable and solid ones like
tetex can decide to disappear into thin air from one day to another, I
wouldn't bind ourselves to versioning and naming of intermediate
upstreams. E.g. I wouldn't even use texlive/tetex prefixes to
subpackages and dependencies. After all a package requiring some
version of LaTeX or dvips doesn't require that it comes from tetex,
TeXlive etc., so the dependency should be kept subvendor-free.

IOT the tetex/texlive prefixing is separate from
perl/python/... prefixing as tetex/texlive is a vendor string, not the
real universe which would probably be simply "tex".

(The current packages go into the right direction wrt above, e.g.:
 texlive-2007-7
 texlive-afm-2007-7
 texlive-dvips-2007-7
 texlive-dviutils-2007-7
 texlive-latex-2007-7
 kpathsea-2007-7
 kpathsea-devel-2007-7
 xdvi-22.84.12-7
 dvipng-1.9-7
 mendexk-2.6e-7
 dvipdfm-0.13.2d-7
 dvipdfmx-0-7
 Ideally latex, dvips etc will also land into their "own" subpackage)
-- 
Axel.Thimm at ATrpms.net