?

Log in

No account? Create an account
debian vs gtkhtml - LogJam [entries|archive|friends|userinfo]
LogJam

[ website | LogJam ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

debian vs gtkhtml [Feb. 17th, 2004|09:33 pm]
LogJam
logjam
[evan]
LogJam 4.3 hit Debian:

logjam (4.3.0-1) unstable; urgency=low
[...]
   * Drop gtkhtml3 support, there are way too many dependencies for so
     little functionality. (Closes: #199747)

This sucks. I understand compwiz's position but it punishes the end user.

Options:
  • leave gtkhtml out of binaries (displeases pretty much everyone who has to use them, as you lose html preview and offline browsing)
  • include gtkhtml in debian binaries (displeases people who don't want gtkhtml dependencies)
  • make gtkhtml required (displeases everybody who for some reason can't figure out how to get a linux distro where dependencies aren't a problem)
  • make my own debian packages
Thoughts?
LinkReply

Comments:
[User Picture]From: brad
2004-02-17 09:44 pm (UTC)
Try and load the library at runtime. Then the package can just suggest it.

Now I assume you'll tell me the billion reasons why that's hard/impossible/ugly/unsupported?
(Reply) (Thread)
From: evan
2004-02-18 12:30 am (UTC)

Re:

Yes. :)
(Reply) (Parent) (Thread)
[User Picture]From: gaal
2004-02-18 04:29 am (UTC)
Hmmm, the xmms complexity arose from wanting to do some complie-time differentiation as well as run-time. If we limit it to g_module and runtime only, it won't be that bad, no? IIRC there are only a handful of functions we call into gtkhtml3, so it's a few global function pointers to keep in preview.c .

Am I missing something?
(Reply) (Parent) (Thread)
From: evan
2004-02-18 08:43 am (UTC)

Re:

More bug report overhead (how many times did we get "XMMS didn't work!") due to weird library setups. I'd rather say it's there or it isn't at configure time unless the maintainer knows what they're doing.
(Reply) (Parent) (Thread)
[User Picture]From: kumokasumi
2004-02-17 09:45 pm (UTC)

Option 2

It seems to me that chances are good that the subset of Debian boxes that would be running logjam in the first place can just shut up and deal with gtkhtml and its dependencies without too much pain.
compwiz cited an incorrect bug number in the changelog and I'm not sure where the initial report was, but IIRC they were complaning about something like 20MB worth of binaries; sure, it's wasteful, but I don't understand why it's worth complaning about in the Modern Era of cheap, easy storage.

Bah; I'd been waiting for 4.3 to hit unstable before playing with it, but I'll just bite the bullet and work with the source if gtkhtml isn't in the .deb.
(Reply) (Thread)
From: piman
2004-02-18 07:08 am (UTC)

Re: Option 2

I agree with this one. Even if you don't "use GNOME", it's rare to have a system without the core libraries installed these days (for something -- Rhythmbox, Evolution, Galeon, and Acme all come to mind as things my friends who don't use GNOME, still use regularly).
(Reply) (Parent) (Thread)
From: compwiz
2004-02-18 05:13 pm (UTC)
I don't use any of those applications, and I _do_ use GNOME. Considering there are alternatives for pretty much all of those for KDE, why force people to install libraries they don't need?
(Reply) (Parent) (Thread)
[User Picture]From: jamincollins
2004-02-18 08:15 am (UTC)
I for one don't use Gnome and try to avoid any app that would bring in it's dependancies. I've found that for each app that would pulling in a number of Gnome dependancies, there is usually a similar app that doesn't.

The correct bug number is #197747
(Reply) (Parent) (Thread)
From: technoshaman
2004-02-17 11:15 pm (UTC)
Solution (ugly, but...):

Two different packages.

logjam, sans gtkhtml

logjam-gtkhtml: full monty

(Reply) (Thread)
[User Picture]From: topher
2004-02-18 02:05 am (UTC)

Re: Multiple packages.

This would be my suggestion, and seems to be the most common way to deal with this situation in other packages.

Either that, or try to modularize the gtkhtml support in such a way that the program can either detect, or be told, whether gtkhtml is available, and use it when it is, or work around it when it isn't. Then gtkhtml could be suggested/recommended, instead of depended upon. (This requires more work for the software author, and less for the packager).
(Reply) (Parent) (Thread)
From: compwiz
2004-02-18 05:21 pm (UTC)
and an easier time for the end-user. rather than look at the two packages and scratch their head figuring out which one to install, they could just install the suggested gtkhtml package if they so choose, and they automatically have HTML rendering support.
(Reply) (Parent) (Thread)
[User Picture]From: lyspeth
2004-02-18 03:19 pm (UTC)

Re:

This sounds like a workable solution...I know I for one really want gtkhtml functionality in the Debian package!
(Reply) (Parent) (Thread)
[User Picture]From: substitute
2004-02-17 11:24 pm (UTC)
It might be worthwhile to try and get the gtkhtml maintainer to fix the distribution. I had to manually add various packages to get it to install at least on debian sid because it was handly dependencies so poorly that the issue wasn't the 20 MB as much as the tiresome business of figuring out dependencies on one's own. I don't think anyone who's installing logjam is worrying about a few extra gtk/gnome packages as overhead.
(Reply) (Thread)
From: compwiz
2004-02-18 05:23 pm (UTC)
what's wrong with gtkhtml2?
(Reply) (Thread)
From: evan
2004-02-18 05:41 pm (UTC)

Re:

haven't ever looked at it!
(Reply) (Parent) (Thread)
From: compwiz
2004-02-18 05:44 pm (UTC)
Would be worth looking at. It's actually stable (gtkhtml3 is keeping logjam out of testing), and the GNOME help browser & GIMP 2.0 use it. Doesn't depend on an arm and a leg, either.
(Reply) (Parent) (Thread)