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
Attachment:
pgpF7KYNrMimF.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
