Re: (post-Etch) Turning tetex-* packages into dummy dependency metapackages
Frank Küster wrote:
> At least for the packages that build-depend on tetex, I think it's worth
> the effort to bug the maintainers to choose the minimal set of needed
> texlive packages manually. Whether we also manage this for
> Depends/Recommends is a different story (and will, e.g., depend on the
> extent I'll be still involved in maintenance next year, with (I hope) a
> new job). But for the buildds, I'd really like to avoid the extra load
> of installing all that stuff.
To be honest, I was thinking of it (dummy packages) only as a way to
give users smooth Etch -> Lenny upgrades, if they hadn't switched over
to TeXLive yet. The point that developers would take advantage of them,
in order not to bother changing their (Build-)Depends, didn't really
occur to me.
If that's the main concern, I could suggest having the real tetex-*
packages removed from Sid soon after the Etch release, and then
re-introduced as dummy packages (generated by TeXLive source?) only
toward the end of the Lenny release cycle. That would force maintainers
to update their Build-Depends and Depends in the meantime.
The other point you raise, that tetex-* dummy packages would have to
depend on a huge amount of stuff! is of course valid. The problem is
that the way in which teTeX packages are split up is more or less
orthogonal to the split for TeXLive in Debian.
> No, rather tetex-bin should stop providing dvipdfm, and any package
> depending on it should choose proper dependencies. dvipdfm was never
> meant to be a virtual package, there's no defined functionality and
> nothing. It just existed as a separate package in woody, and since
> teTeX took over, tetex-bin Conflicts/Replaces/Provides it.
Should I go ahead and file a bug against alml? What severity?
Kevin B. McCarty <firstname.lastname@example.org> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544