Re: (fwd) Re: Bug#381467: bibtex2html: please provide alternative dependency on texlive packages
Norbert Preining <preining@logic.at> wrote:
> Hi all!
>
> I forward you an email discussion about alternative dependencies on
> texlive. The maintainers of bibtex2html (and Sven Luther) consider it
> a bad idea to add everywhere the alternative dependencies and suggest to
> create virtual packages, or make texlive provide tetex-base/bin/extra.
Shouldn't we talk *with* Sven instead of "about" his texts?
Executive summary of my opinion:
It would be nice to have a virtual package targetted at build-depends
and taylored so that generated code (texinfo, sgml2..., linuxdoc,
debiandoc,...) works with it. I won't do the work of collecting a
list, at least not before etch.
> Please read through this and share your comments.
So here's my comments. One remark in advance:
Many packages have wrong dependencies on tetex anyway, like "Depends:
tetex-base, tetex-bin" which doesn't make sense. This will complicate
any improvements, and require depending packages to change their
control files even if we "do it right". For example, if we create a
virtual package for "Basic, Required and Some LaTeX Stuff", call it
tetex-bin and let texlive-latex-base (or however), such a package will
not work with texlive because of the dependency on tetex-base.
> Not completely wrong, but unrealistic. You might reconsider your
> decision in the light of the following points:
> - tetex is not actively maintained any more (upstream, not debian)
> - texlive is actively maintained and has regular release cycles every
> year
> - for sure not etch, but etch+1 will (?) have texlive as default tex
> system
> - there is no other TeX implementation around one would want to package
> for Debian.
Hm. There is the MikTeX installer which has been ported to Linux. This
might be the germ or a new cross-platform TeX distribution. Because of
the installer concept, splitting or rather aggregating Debian packages
of that distribution is likely to be a task for the Debian maintainers,
and can easily be done in a way that every miktex package corresponds to
a texlive sister.
> Anyway, it is a wishlist bug. You can ignore it, or raise it yourself to
> debian-devel. But one think is sure: the introduction of a virtual
> package *WILL NOT WORK*, because what should the virtual package
> provide: a basic latex system only with the required components of a
> latex system (that are not a lot)? Or a specific subset of packages?
> This doesn't work, you, the one depending on tex implementations, have
> to say *what* you need, and choose the respective packages.
For Build-Dependencies a virtual package might work, since most packages
use something-to-LaTeX-converters which always require the same style
files. But then there's the complication that the style files required
by code generators might be in different tpm collections, so we have to
arrange with upstream (the TeXLive list).
>> 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.
This is a dream. For real (non Build-) deps, the only save virtual
package would depend on tetex-extra | texlive-full, which is insane.
>> > 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.
We can vote and decide, but that won't change reality. And reality is
that people will request changes, and rather sooner than later one
request among the "please add foo.sty" will be to have a smaller virtual
package because it pulls in so many unneeded things...
>> 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).
Given the non-granularity of tetex, and its being dead, this doesn't
make sense. If you want to have granular dependencies, take what
already exists: depend on texlive. tetex is even more weird: Some
required parts of a LaTeX system are in tetex-extra. We have plans and
some infrastructure to fix this, but I doubt it will happen: Before
etch, we'll concentrate on license stuff and pressing functionality
issues, and after that it doesn't make sense to invest in tetex
packaging.
>> 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 don't understand what he wants to say here. Why is it more awkward to
change "Depends: tetex-bin" to "Depends: texlive-foo, texlive-bar" than
to change it to depend on a virtual package? And who is "you" that gets
no choice? We or the people depending on TeX? And why does the current
setup not help - it may be not nice, but it works.
>> 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.
Two months before a freeze I wouldn't call "early phase". The texlive
packages may be in an early phase of packaging, yes. But also, I don't
see how "doing it right" would lead to more than one virtual package,
and this should be introduced with care and thought.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: