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

[Axel Thimm]

On Sun, Jan 06, 2008 at 03:02:51PM +0100, Patrice Dumas wrote:
> > (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)
> 
> I don't think so. The package name should be what upstream is.

Upstream versions latex with version "2005/12/01" (one could argue
whether fixltx2e makes that "2006/03/24" instead).

This is quite distinct from texlive-latex-2007. Or seen from a
different perspective: If naming/versioning latex as
texlive-latex-2007 is fine, why isn't texlive-xdvi-2007 fine as well?

> It's up to the virtual provides to provide vendor independance.

Of course, if you

a) have these virtual provides
b) make this public enough that packagers use them instead of the
   package names (and really how many packagers check to see whether
   some dependent on package provides some virtual entities that they
   should pull in instead, and more importantly how certain can this
   packager be that this virtual Provides: will be around long enough
   and not have his package broken by the next texlive package
   update?).
c) rpm, yum and friends deal better with virtual provides vs real
   entities than they do now. Thankfully the aged bug on packages
   auto-obsoleting when providing a virtual dependency has been
   recently fixed, but not yet in the rpms we use (I think so at
   least, perhaps F8 has the fix), and more importantly it created
   confusion and aversion to using virtual provides for upgrade paths
   and that's what this is about.

Instead it would be better to have the real package names prompty
display to other packagers what they should require and keep
compatibility provides internally.
-- 
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/20080106/bf3e1171/attachment.sig>