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

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

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.

Please read through this and share your comments.

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
-------------------------------------------------------------------------------
LUTON (n.)
The horseshoe-shaped rug which goes around a lavatory seat.
			--- Douglas Adams, The Meaning of Liff
--- Begin Message --- 
Hi Stefano!

On Fre, 04 Aug 2006, Stefano Zacchiroli wrote:
> I don't think "polluting" all packages that need tetex-whatever with
> alternative dependencies on texlive-whatever is a good idea. It would be
> much better to make both tetex-whatever and texlive-whatever Provides a
> virtual package like latex-whatever and then ask all interested packages
> to use a dependencies on the virtual package.
> 
> 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?

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.

We, the TeX for Debian maintainers (that is all those working on teTeX,
TeX live and related packages), have catered for this, and currently the
two systems coexist, and in fact cooperate to a certain level (you can
use texlive packages with tetex).

But rest assured, the X minutes you would invest in adding the
additional dependency will not have to be done again and again
(considering that the initial packaging texlive was a task of 1 year, I
assume not many will come forth and package a currently non-existent TeX
distribution).

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.

Ciao ciao e forse ci vediamo a Bologna, non è lontano da Siena!

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
-------------------------------------------------------------------------------
TIGHARRY (n.)
The accomplice or 'lure' who gets punters to participate in the three
card trick on London streets by winning an improbable amount of money
very easily.
			--- Douglas Adams, The Meaning of Liff

--- End Message ---
--- Begin Message --- 
On Fri, Aug 04, 2006 at 10:09:45PM +0200, Norbert Preining wrote:
> Hi Stefano!
> 
> On Fre, 04 Aug 2006, Stefano Zacchiroli wrote:
> > I don't think "polluting" all packages that need tetex-whatever with
> > alternative dependencies on texlive-whatever is a good idea. It would be
> > much better to make both tetex-whatever and texlive-whatever Provides a
> > virtual package like latex-whatever and then ask all interested packages
> > to use a dependencies on the virtual package.
> > 
> > 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?
> 
> 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.
> 
> We, the TeX for Debian maintainers (that is all those working on teTeX,
> TeX live and related packages), have catered for this, and currently the
> two systems coexist, and in fact cooperate to a certain level (you can
> use texlive packages with tetex).
> 
> But rest assured, the X minutes you would invest in adding the
> additional dependency will not have to be done again and again
> (considering that the initial packaging texlive was a task of 1 year, I
> assume not many will come forth and package a currently non-existent TeX
> distribution).
> 
> 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.

Is texlive a full replacement of tetex ? If so, would having texlive provide a
Provide: tetex-base or whatever not have been the way to go an the easiest
solution, instead of bothering a huge amount of maintainer with the change ? 

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.

Friendly,

Sven Luther

--- End Message ---
--- Begin Message --- 
On Fre, 04 Aug 2006, Sven Luther wrote:
> Is texlive a full replacement of tetex ? If so, would having texlive provide a
> Provide: tetex-base or whatever not have been the way to go an the easiest
> solution, instead of bothering a huge amount of maintainer with the change ? 

Unfortunately not, as - AFAIR - providing an actual package does not
work in the presence of the real package. That works in case of virtual
packages and in the absence of a real package.

Furthermore, still tetex is the option of choice, the texlive packaging
for Debian is too young to be completey ready.

> 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
content, not even all of the TeX Debian maintainers (some are
mathematicians, physicians, chemistry, linguist, or nothing at all).
This is the problem, there is *no* defined subset of minimal packages.
TeX live has started to categorize this into packages (as mirrored by
the texlive packages), but this changes permanently, and is open to
suggestions.

We know that it would be easier to have a simple virtual packages, but
it doesn't work. Eg. the package ipe needs special fonts from
tetex-extra. And it depends in which texlive package these fonts are.
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".

I think that the burden to the developers to change the depends line is
not soo big. Especially since I already suggested an extension.

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
-------------------------------------------------------------------------------
The main reception foyer was almost empty but Ford
nevertheless weaved his way through it.
                 --- Ford making his way out of Milliways whilst under the
                 --- influence of enough alchol to make a rhino sing.
                 --- Douglas Adams, The Hitchhikers Guide to the Galaxy

--- End Message ---
--- Begin Message --- 
On Sat, Aug 05, 2006 at 12:23:43AM +0200, Norbert Preining wrote:
> On Fre, 04 Aug 2006, Sven Luther wrote:
> > Is texlive a full replacement of tetex ? If so, would having texlive provide a
> > Provide: tetex-base or whatever not have been the way to go an the easiest
> > solution, instead of bothering a huge amount of maintainer with the change ? 
> 
> Unfortunately not, as - AFAIR - providing an actual package does not
> work in the presence of the real package. That works in case of virtual
> packages and in the absence of a real package.

It sure works. If you have texlive installed, it will satisfy the dependency.
The only problem is that it will be tetex which will be pulled in by default
if nothing is installed, but ...

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

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

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

> This is the problem, there is *no* defined subset of minimal packages.
> TeX live has started to categorize this into packages (as mirrored by
> the texlive packages), but this changes permanently, and is open to
> suggestions.

Sure, and the policy can be changed to as response to suggestions, a bit more
akwardly maybe, but still. And adding packages to it is backward compatible.

> We know that it would be easier to have a simple virtual packages, but
> it doesn't work. Eg. the package ipe needs special fonts from

Have you tried it to say it doesn't work ? We, the ocaml team, have a lot of
experience with virtual packages, and it works quite nicely, so i have some
serious doubts about your "it doesn't work" claim. Especially given your
comments above :)

> tetex-extra. And it depends in which texlive package these fonts are.

Well, you can use a metapackage which depends on all the fonts, or use a
special clasification of those fonts, and have various virtual packages on
those fonts subsets which provide specific fonts.

It may even be possible, but i am not sure if this would work, to use the
reverse-depends thingy (extends) to create a virtual package in the absence of
a metapackage which pulls in all the fonts. This would be a neat trick, but
probably need some work on the part of the dpkg/apt/whatever guys.

> 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 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.
Please consider the virtual package solution well before dismissing it out of
hand or at least without having checked the situation in details.

Friendly,

Sven Luther

--- End Message ---
Reply to: