Your message dated Sun, 6 Jul 2008 08:01:15 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#489468: libwebkit-1.0-1: should libwebkit be 
gtk-specific?
has caused the Debian Bug report #489468,
regarding libwebkit-1.0-1: should libwebkit be gtk-specific?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
489468: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489468
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: libwebkit-1.0-1
Version: 0~svn32442-1
Severity: normal

the description for libwebkit currently seems to indicate that it is
for gtk-based browers only.  

$ apt-cache show libwebkit-1.0-1 | grep Description
Description: Web content engine library for Gtk+

this has lead to some aversion from qt-based webkit browser packagers [1].  
would it make sense to remove the "for Gtk+" part from the package 
description?

hopefully someday the two webkits can be merged so that only one webkit
library is in the archive (advantages: reduced maintainance overhead, 
single code base to implement security fixes for, less libraries to 
load into memory, etc.).

thank you for your consideration.

[1] http://bugs.debian.org/479851

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-6-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libwebkit-1.0-1 depends on:
ii  libc6                      2.7-12        GNU C Library: Shared libraries
ii  libcairo2                  1.6.4-6       The Cairo 2D vector graphics libra
ii  libcurl3-gnutls            7.18.2-5      Multi-protocol file transfer libra
ii  libfontconfig1             2.6.0-1       generic font configuration library
ii  libfreetype6               2.3.7-1       FreeType 2 font engine, shared lib
ii  libgcc1                    1:4.3.1-4     GCC support library
ii  libglib2.0-0               2.16.4-1      The GLib library of C routines
ii  libgtk2.0-0                2.12.10-2     The GTK+ graphical user interface 
ii  libicu38                   3.8.1-2       International Components for Unico
ii  libjpeg62                  6b-14         The Independent JPEG Group's JPEG 
ii  libpango1.0-0              1.20.4-1      Layout and rendering of internatio
ii  libpng12-0                 1.2.27-1      PNG library - runtime
ii  libsqlite3-0               3.5.9-3       SQLite 3 shared library
ii  libstdc++6                 4.3.1-4       The GNU Standard C++ Library v3
ii  libxml2                    2.6.32.dfsg-2 GNOME XML library
ii  libxslt1.1                 1.1.24-1      XSLT processing library - runtime 

libwebkit-1.0-1 recommends no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
On Sat, Jul 05, 2008 at 09:15:51PM -0400, Michael Gilbert wrote:
> Package: libwebkit-1.0-1
> Version: 0~svn32442-1
> Severity: normal
> 
> the description for libwebkit currently seems to indicate that it is
> for gtk-based browers only.  
> 
> $ apt-cache show libwebkit-1.0-1 | grep Description
> Description: Web content engine library for Gtk+
> 
> this has lead to some aversion from qt-based webkit browser packagers [1].  
> would it make sense to remove the "for Gtk+" part from the package 
> description?

No, because this *is* the webkit library for Gtk+. The one for qt is in
another package, from another source.

> hopefully someday the two webkits can be merged so that only one webkit
> library is in the archive (advantages: reduced maintainance overhead, 
> single code base to implement security fixes for, less libraries to 
> load into memory, etc.).

Don't count too much on that. The best that will be possible will be to
share the javascript engine.

Mike


--- End Message ---

Reply via email to