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