Description of problem: With the move from tetex to texlive, add-on packages will need to be adjusted. In particular, add-on packages Requires: tetex and the like will need to be updated. This gives us a good opportunity to make allowance for other TeX distributions in the process - it is frequently the case that add-on packages are agnostic as to the particular TeX distribution in use, so simply replacing Requires: tetex with Requires: texlive isn't the cleverest option. Rather it would be better if texlive packages had some sensible virtual provides, such that add-ons could require those. Then, if a user has another TeX distribution installed, as long as it has the same virtual provides, the add-on packages can still be used. A use case would be a user working at an institution that has its own in-house customised TeX distribution. Question then becomes, what is a sensible granularity of the virtual provides, and how should they be named. Some starting points: Provides: TeX Provides: LaTeX or perhaps Provides: tex Provides: tex(dvips) Provides: tex(latex) Provides: tex(fonts) ... etc. Views welcome. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I like the second approach you presented, i.e. to add the tex prefix to all TeX virtual provides, but I would change the brackets to: Provides: tex-dvips Provides: tex-latex Provides: tex-fonts ... so that a new package can be named, say tex-fonts-chinese itself and thus needn't to contain explicit virtual Provides, but real Provides. Do you agree?
(In reply to comment #1) > I like the second approach you presented, i.e. to add the tex prefix to all TeX > virtual provides, but I would change the brackets to: > > Provides: tex-dvips > Provides: tex-latex > Provides: tex-fonts > ... > > so that a new package can be named, say tex-fonts-chinese itself and thus > needn't to contain explicit virtual Provides, but real Provides. Do you agree? I don't think this is a good idea, since it removes the very use of those provides, allowing for different implementation to provide the capacity. In any case I think that we should avoid as much as possible the virtual provides. everytime a precise command is needed it is better to have it as an explicit Requires, like Requires: %{_bindir}/dvips In my opinion we should first introduce as few as possible virtual provides, namely tex latex or tex tex(latex) and only add more when there is a proved need.
Possible virtual provides to current texlive: tex tex-doc tex-dvips tex-fonts tex-latex tex-dvipdfm tex-dvipdfmx tex-dvipng tex-kpathsea tex-kpathsea-devel tex-mendexk tex-dviutils tex-xdvi It doesn't make sense IMO to have tex-texmf-* virtual provides as the binaries requires and requires the texmf related stuff anyway and the standalone texmf tree parts exclusively seem to be useless to me. I.e. no package that I imagine would need such a separation. Or not? Also the question is how to version the "tex" virtual provide, because it doesn't make sense to leave it unversioned as it would be then impossible to obsolete it by a newer version, i.e. a newer TeX distribution for instance.
(In reply to comment #1) > I like the second approach you presented, i.e. to add the tex prefix to all TeX > virtual provides, but I would change the brackets to: > > Provides: tex-dvips > Provides: tex-latex > Provides: tex-fonts > ... > > so that a new package can be named, say tex-fonts-chinese itself and thus > needn't to contain explicit virtual Provides, but real Provides. Do you agree? I don't have strong feelings about hyphenation vs. using parentheses, but I have noticed that there's a lot of packages using parentheses for virtual provides. I don't know what the history behind that is though. I imagine there's no hard and fast rule, and you're reasons for preferring the hyphenation seem good to me.
(In reply to comment #4) > (In reply to comment #1) > > I like the second approach you presented, i.e. to add the tex prefix to all TeX > > virtual provides, but I would change the brackets to: > > > > Provides: tex-dvips > > Provides: tex-latex > > Provides: tex-fonts > > ... > > > > so that a new package can be named, say tex-fonts-chinese itself and thus > > needn't to contain explicit virtual Provides, but real Provides. Do you agree? > > I don't have strong feelings about hyphenation vs. using parentheses, but I have > noticed that there's a lot of packages using parentheses for virtual provides. I > don't know what the history behind that is though. I imagine there's no hard and > fast rule, and you're reasons for preferring the hyphenation seem good to me. > I don't know esactly, but I think that parenthesis are used for the reason I stated above, avoid clash with real package names.
(In reply to comment #3) > would need such a separation. Or not? It could be that a package only needs a directory ownership and not the commands. However, since the texmf packages need the main packages for the scripts it doesn't make sense to have both. Currently the following are used: tetex-dvips tetex-fonts tetex-latex tetex-xdvi (arch only) But I think that we don't need the font and dvips ones since they are very intricated with the main tex package. I think we should avoid an xdvi virtual provides, there is no reason for such provides, and in general there should be no dependency on xdvi, but on xdg-utils. > Also the question is how to version the "tex" virtual provide, because it > doesn't make sense to leave it unversioned as it would be then impossible to > obsolete it by a newer version, i.e. a newer TeX distribution for instance. Why use the virtual provides for that? And not the real package names? The versionning is only useful if there are capabilities associated with the virtual provides that evolves over time, such that one needs to have something recent enough to support a feature. Is it such a need for tex/latex?
(In reply to comment #6) > (In reply to comment #3) > > Also the question is how to version the "tex" virtual provide, because it > > doesn't make sense to leave it unversioned as it would be then impossible to > > obsolete it by a newer version, i.e. a newer TeX distribution for instance. > > Why use the virtual provides for that? And not the real package names? Because we want other apps to Require: tex instead (tetex/texlive) > The versionning is only useful if there are capabilities associated > with the virtual provides that evolves over time, such that one needs > to have something recent enough to support a feature. Is it such a need > for tex/latex? Yes. We need versioned tex virtual provides to make the others dependent on it. Just in case of texlive I propose to have: Provides: tex = 2007 in texlive. The version '2007' is not somehow connected to the texlive version, but should be used to change with next major TeX upgrade, which is not likely to be more frequent that once per year. This will give us an opportunity to safely upgrade TeX.
imo, comment #3 is right on, and use texlive's versioning. When/if it needs to be Obsoleted by something else, an Epoch could be introduced if necessary.
(In reply to comment #7) > Because we want other apps to Require: tex instead (tetex/texlive) We can have a plain Provides: tex and have texmore obsoletes texlive. > > The versionning is only useful if there are capabilities associated > > with the virtual provides that evolves over time, such that one needs > > to have something recent enough to support a feature. Is it such a need > > for tex/latex? > > Yes. We need versioned tex virtual provides to make the others dependent on it. > Just in case of texlive I propose to have: > > Provides: tex = 2007 > > in texlive. The version '2007' is not somehow connected to the texlive version, > but should be used to change with next major TeX upgrade, which is not likely to > be more frequent that once per year. This will give us an opportunity to safely > upgrade TeX. I don't think we should increase this number automatically, but only when there is a need. Something similar with a soname. In my opinion we should only bump it when there is a real need. Are there currently versioned tetex requires?
(In reply to comment #8) > imo, comment #3 is right on, and use texlive's versioning. When/if it needs to > be Obsoleted by something else, an Epoch could be introduced if necessary. I think that it is a bad idea ti tight the virtual provides version with a particular release. It should be tied to a set of functionalities. TeX is very stable and the need for versionned provides should be very rare.
If you think versioned provides would be rarely needed, then why is it a bad idea again? I'd argue unversioned Provides or Obsoletes, in general, is simply bad practice, and should be avoided, unless there is some very good reason. As-is, I fail to see any current "good reason".
Indeed there is no really good reason not to version it. And also using the texlive year is not a bad choice. I would have prefered a numbering corresponding with a set of functionalities, but admitedly this would certainly be hard to determine and using the texlive major release ensures that no interesting version is skipped, and even though there are too much versions, too much is better than not enough. However I think that it is a bad idea to introduce epochs when a new tex system is out. Just increment the virtual provides, even though it is disconnected from a real year.
After more thinking, I think that it makes sense to have tex tex-latex or tex(latex) tex-dvips or tex(dvips) since even though tex and tex(dvips) will certainly be installed together, the tex(dvips) provides corresponds with the dvips program and associated files, without the need to have a path (like %{_bindir}/dvips) when dvips is not called with a path. Still I think that tex and tex(fonts) should not be separated. tex(xdvi) seems unuseful to me, or better should never be used. the kpathsea requires should be either sonames or real kpathsea-devel provides in my opinion, having parallel installable devel packages are likely to be complicated and confusing.
I really think that virtual provides should have parenthesis in order to avoid clashing with a package name. Indeed, if there is a package with the same name, then rpm will always prefer this package against the package providing the virtual provides even if the virtual provides has higher version. So I really insist on using the virtual provides: tex(tex) tex(latex) tex(dvips)
I tend to agree with Patrice regarding parentheses, on balance, having seen the weird ways that rpm currently handles virtual provides versioning.
Ok, I changed the virtual provides to the paretheses style.