Bug#381467: bibtex2html: please provide alternative dependency on texlive packages
On Sat, Aug 05, 2006 at 12:23:43AM +0200, Norbert Preining wrote:
> On Fre, 04 Aug 2006, Sven Luther wrote:
> > Is texlive a full replacement of tetex ? If so, would having texlive provide a
> > Provide: tetex-base or whatever not have been the way to go an the easiest
> > solution, instead of bothering a huge amount of maintainer with the change ?
>
> Unfortunately not, as - AFAIR - providing an actual package does not
> work in the presence of the real package. That works in case of virtual
> packages and in the absence of a real package.
It sure works. If you have texlive installed, it will satisfy the dependency.
The only problem is that it will be tetex which will be pulled in by default
if nothing is installed, but ...
> Furthermore, still tetex is the option of choice, the texlive packaging
> for Debian is too young to be completey ready.
... given that tetex is the option of choice, at least for now, this is indeed
the expected behaviour, and is exactly what you obtain with your alternative
thingy anyway.
This way, once you decide to kill tetex and replace it with texlive, you only
need to remove tetex from the archive, and everything will work automatically.
> > And you can easily say that the latex-base package will have to provide the
> > subset of packages defined in the latex policy, and everyone should be happy.
>
> But who will define this subset? There is no subset which makes all
The tex/latex maintainer team, naturally, who else ? Once it is defined in the
policy, everyone is aware of that, and know what to expect.
> content, not even all of the TeX Debian maintainers (some are
> mathematicians, physicians, chemistry, linguist, or nothing at all).
Well, you could vote on it, or come to a consensus or something. There could
be various such subsets even (latex-base, latex-extra or latex-math,
latex-science, or whatever).
> This is the problem, there is *no* defined subset of minimal packages.
> TeX live has started to categorize this into packages (as mirrored by
> the texlive packages), but this changes permanently, and is open to
> suggestions.
Sure, and the policy can be changed to as response to suggestions, a bit more
akwardly maybe, but still. And adding packages to it is backward compatible.
> We know that it would be easier to have a simple virtual packages, but
> it doesn't work. Eg. the package ipe needs special fonts from
Have you tried it to say it doesn't work ? We, the ocaml team, have a lot of
experience with virtual packages, and it works quite nicely, so i have some
serious doubts about your "it doesn't work" claim. Especially given your
comments above :)
> tetex-extra. And it depends in which texlive package these fonts are.
Well, you can use a metapackage which depends on all the fonts, or use a
special clasification of those fonts, and have various virtual packages on
those fonts subsets which provide specific fonts.
It may even be possible, but i am not sure if this would work, to use the
reverse-depends thingy (extends) to create a virtual package in the absence of
a metapackage which pulls in all the fonts. This would be a neat trick, but
probably need some work on the part of the dpkg/apt/whatever guys.
> Other Debian packages need the listings.sty (lyx AFAIR), etc etc. It all
> depends on the intended target audience of the package, which sty files
> it considers as "basic".
Indeed. and those packages with specific aims should depend directly on the
given texlive subpackages, but this is awkward until texlive is the default.
So you get no choice but to wait for this transition, and have them adapted
then, and use a global metapackage until then. Your current alternative
dependency doesn't really help there.
> I think that the burden to the developers to change the depends line is
> not soo big. Especially since I already suggested an extension.
Well, but there is such a thing as "doing it right" instead of going for a
hacky workaround. Especially in an early phase of such a big restructuration.
Please consider the virtual package solution well before dismissing it out of
hand or at least without having checked the situation in details.
Friendly,
Sven Luther
Reply to: