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

Re: Bug#381467: bibtex2html: please provide alternative dependency on texlive packages



Hi Frank!

(BTW: How was the water in Sardegna, I want to go there in 2 weeks? I
hope you two had a nice week with good weather!)

On Die, 15 Aug 2006, Frank Küster wrote:
> Shouldn't we talk *with* Sven instead of "about" his texts?

I have forwarded Sven your answer and put him onto the Cc list. If he
wants to get off the discussion please tell us!

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

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

Well, we would call it latex-base or something like this, and this one
would depend on whatever tetex/texlive packages necessary.

> > - 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. In fact they use the TeXlive tpms and add
some additional information in the tpms. I am in discussion with Karl
about using miktex packages to update the texlive in case the miktex one
is newer etc. But in fact miktex will have the same problems, and is
based on TeXlive, again AFAIR.

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

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

This can be done.

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

I agree that for now and at least etch+1 we will have tetex as default.

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

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

With 2005.dfsg.1-1 the texlive packages have fixed a similar problem,
now the required parts are in latex/fonts-recommended, which makes
sense.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at>             Università di Siena
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
IPING (participial vb.)
The increasingly anxious shifting from leg to leg you go through when
you are desperate to go to the lavatory and the person you are talking
to keeps on remembering a few final things he want to mention.
			--- Douglas Adams, The Meaning of Liff



Reply to: