On Sun, Jan 06, 2008 at 09:44:38PM +0200, Axel Thimm wrote: > > Upstream versions latex with version "2005/12/01" (one could argue > whether fixltx2e makes that "2006/03/24" instead). That could be a good idea for numbering the virtual provides in my opinion. > 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? Because xdvi is really a distinct package with its own upstream. It has just been submitted anyway, so this issue won't be there for long. > > 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?). We will make sure that only the virtual provides are used. Hopefully it will become a guideline. Just like the python and emacs virtual provides. > 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. It has to work rergardless of texlive/tex. It is a requirement for alternate provides. > 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. Why internally? They are here exactly for independence with regard with tex distribution vendor, so must be virtual. (It is certainly not for soon, but we could even imagine packaging 2 tex distros in parallel in fedora). Having a) and b) is the plan, as for c) it has to be fixed anyway. In th emean time, the tetex-* provides can be kept (and will have to for a long period of time in EPEL anyway). -- Pat -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
