Re: Bug#381467: bibtex2html: please provide alternative dependency on texlive packages
Hi Ocaml people,
this discussion has continued a bit on the TeX mailing list, but I think
we should rather discuss it together. I also don't think that it makes
sense to move to -devel at this moment, because as I see it we should
first try to get a grip on the facts (including your motives for arguing
against the alternatives in the control file).
Putting a summary at the beginning:
I think that a virtual package "latex-base" or similar would make sense
in the long run. But it would require quite some work - and maintainers
would still have to change their control files, plus check that the
virtual package is sufficient for them. Because of this necessecity to
check for other texlive packages, I do not think that such a virtual
package will be used much, anyway. The only frequent use that I see is
for code generators (from docbook, texinfo, sgml, xml) who would
coordinate with the TeX maintainers that their code can be typeset with
only the virtual package installed.
Therefore I suggest to start with fixing these bugs and allowing texlive
as an alternative dependency.
Norbert Preining <preining@logic.at> wrote:
> On Die, 15 Aug 2006, Frank Küster wrote:
[...]
>> 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.
>
> What about contacting *all* TeX dependent maintainers and ask them what
> they consider as basic latex support (which packages) as a start?
I doubt that this will bring us much further: Most maintainers (or
upstream developers) of packages depending on LaTeX just use what they
need, or even what they have been told to use, without much
understanding of relationships between packages, their development
status etc. But let's do it, at least if we have settled that we do
want such a package.
>> 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
^provide it
>> not work with texlive because of the dependency on tetex-base.
>
> Well, we would call it latex-base or something like this, and this one
> would depend on whatever tetex/texlive packages necessary.
Yes, but the point of this remark (you snipped it) was that many
packages declare Depends: tetex-base, tetex-bin, or even: tetex-base,
tetex-bin, tetex-extra, and therefore would need to have their control
file fixed, anyway. An other reason why I think that introducing a
virtual package would not safe time or changes at all for many packages.
Therefore it boils down to this argument from the bug log:
,----
| This way we would at least have to do the work once, what if tomorrow we
| will add in debian another latex implementation? Should we go through
| all the involved packages again?
`----
(nitpicking, just to keep things correct in the archive: Because of the
LPPL, there's essentially only one definitive "LaTeX implementation",
ever. What we're dealing with here are different TeX distributions,
both including LaTeX).
Norberts answer was:
>> > - 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.
>
> And these would never be included in Debian, or? It would have been
> *MUCH* easier to make for every tpm a debian package, ... and AFAIR
> miktex is based on tpms, too.
Of course, that's why I wrote about aggregating: The hypothetical
maintainer of MikTeX for Debian would have to aggregate Debian packages
from the myriad of MikTeX tpms.
Anyway, although I do not expect that there will be debs for MikTeX in
Debian, we should not preclude that, and be prepared. This means that
we have to thoroughly consider which virtual packages can or should be
provided.
Since both systems would generate their Debian packages from their own
(shared) scheme, without any constraints from upstream, I think the
second could be taylored in parallel to the existing ones, and the names
of the texlive packages could become virtual as well as real package
names. This means that we do not need to provide any special virtual
packages in advance. At least not for the purpose of allowing MikTeX
packaging.
>> > 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
>
> But we need it for Depends, not for Build-Depends.
Don't you think it would be useful for both? In fact I think it would
be more useful for the purpose of package-building, because (as I said
previously) many packages that need a TeX system at build time use code
generators, and it would be easy to adapt the virtual package to the
possibly changing needs of generated code. For packages that are mainly
used during normal operation, often with manually generated documents,
it is much more difficult to come up with a collection of "basic" LaTeX
styles that satisfy most people's needs without getting too bloated.
Ocaml people, do you know which LaTeX packages your packages need, or
have you just written all teTeX packages in the Depends line without
testing?
>> > 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...
>
> Yup. Right. Thats why I think the right solution is that maintainers
> check what the need and add the correct dependencies.
>
> With tetex people were lazy, just adding tetex-bin/-base/-extra and they
> were sure that they have everything the can get. Suddenly with texlive
> they have to actually check (=work) ....
I agree. Compare that to Perl or Python or any other language that
provides many add-on modules or libraries: You don't have virtual
packages "perl-webstuff" or "python-maths" either. And, by the way,
depending on "tetex-base, tetex-bin, tetex-extra" is like depending on
"perl-base, perl-modules, perl".
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: