Bug 410401 - RFE: Virtual provides for tex, latex, dvips, etc
RFE: Virtual provides for tex, latex, dvips, etc
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: texlive (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-04 09:00 EST by Jonathan Underwood
Modified: 2013-07-02 19:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-15 09:03:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2007-12-04 09:00:30 EST
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:
Comment 1 Jindrich Novy 2007-12-10 06:28:23 EST
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?
Comment 2 Patrice Dumas 2007-12-10 06:48:01 EST
(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.
Comment 3 Jindrich Novy 2007-12-10 06:59:01 EST
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.
Comment 4 Jonathan Underwood 2007-12-10 08:46:17 EST
(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.
Comment 5 Patrice Dumas 2007-12-11 05:42:12 EST
(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.
Comment 6 Patrice Dumas 2007-12-11 06:00:42 EST
(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?
Comment 7 Jindrich Novy 2007-12-13 06:58:55 EST
(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.
Comment 8 Rex Dieter 2007-12-13 07:58:04 EST
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.
Comment 9 Patrice Dumas 2007-12-13 10:39:40 EST
(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?
Comment 10 Patrice Dumas 2007-12-13 10:42:27 EST
(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.
Comment 11 Rex Dieter 2007-12-13 11:00:52 EST
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".
Comment 12 Patrice Dumas 2007-12-13 12:15:12 EST
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.
Comment 13 Patrice Dumas 2007-12-13 12:21:13 EST
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.
Comment 14 Patrice Dumas 2008-01-15 03:44:32 EST
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)
Comment 15 Jonathan Underwood 2008-01-15 04:46:47 EST
I tend to agree with Patrice regarding parentheses, on balance, having seen the
weird ways that rpm currently handles virtual provides versioning.
Comment 16 Jindrich Novy 2008-01-15 09:03:38 EST
Ok, I changed the virtual provides to the paretheses style.

Note You need to log in before you can comment on or make changes to this bug.