[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (post-Etch) Turning tetex-* packages into dummy dependency metapackages



"Kevin B. McCarty" <kmccarty@Princeton.EDU> wrote:

> 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.

I'm sure it will happen - just have a look at the usual Depends and
Build-Depends on tetex: Although it is clear that tetex-extra must
depend on tetex-bin, and -bin on -base (it would never be able to
generate its formats without), many Depend on all three, or on -base and
-bin.  Although, you often find (in etch) dependencies on packages that
existed only in woody, in sarge we Conflict/Replace/Provide them.

Too many packages that use or enhance TeX are badly maintained.

> 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.

That would be an option.  But it would also mean that for a while, we
would have to be prepared to NMU those packages that FTBFS because of
this.  Things go faster this way, and in the end it might be less work
compared to summing up all the grep-dctrl'ing, bug-reporting and
severity-raising for the "conservative" approach I had in mind.

But it means that this work will have to be done exactly when the
problems show up,  and fast.  Well, if I've got some time of
unemployment and the new appartment already set up...

> 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.

Well, in a way yes.  The way teTeX is split is also buggy (some things
that are required for LaTeX are in tetex-extra).

> Should I go ahead and file a bug against alml?  What severity?

Already done.  I chose important, because I don't think we should remove
the Provides: dvipdfm at this point in the release cycle.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: