Debian Bug report logs - #184401
mozilla-browser: should conflict with all of the packages it breaks (galeon, skipstone...)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Brian Nelson <pyro@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: mozilla-browser: should conflict with all of the packages it breaks (galeon, skipstone...)

Date: Tue, 11 Mar 2003 18:11:30 -0800

Package: mozilla-browser
Version: 2:1.2.1-10
Severity: grave

If you aren't going to move the library components in mozilla-browser
into a separate library package with a c102 soname, then you need to conflict
with all the packages mozilla-browser breaks since it's been recompiled
with GCC 3.2.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux sirius 2.4.20 #2 Fri Feb 28 17:16:28 PST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages mozilla-browser depends on:
ii  debconf                    1.2.32        Debian configuration management sy
ii  libc6                      2.3.1-14      GNU C Library: Shared libraries an
ii  libgcc1                    1:3.2.3-0pre5 GCC support library
ii  libglib1.2                 1.2.10-8      The GLib library of C routines
ii  libgtk1.2                  1.2.10-14     The GIMP Toolkit set of widgets fo
ii  libnspr4                   2:1.2.1-10    Netscape Portable Runtime Library
ii  libstdc++5                 1:3.2.3-0pre5 The GNU Standard C++ Library v3
ii  psmisc                     21.2-1        Utilities that use the proc filesy
ii  xlibs                      4.2.1-6       X Window System client libraries
ii  zlib1g                     1:1.1.4-11    compression library - runtime

-- debconf information:
* mozilla/dsp: auto
* mozilla/gdkxft_note: 
* mozilla/prefs_note: 
* mozilla/freetype: true

Message #10 received at 184401@bugs.debian.org (full text, mbox, reply):

From: Mark Howard <mh344@cam.ac.uk>

To: 184401@bugs.debian.org

Subject: mozilla-browser: should conflict with all of the packages it breaks

Date: 14 Mar 2003 11:00:36 +0000

Please don't do this.

Just file a few more bug reports on the packages which need recompiling

 (galeon will be uploaded in a few days - we're testing it now)

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh@debian.org | mh@tildemh.com | mh344@cam.ac.uk 

Message #15 received at 184401@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 184401@bugs.debian.org

Cc: Liste de développement Debian <debian-devel-french@lists.debian.org>

Subject: Handling of mozilla libraries

Date: 17 Mar 2003 18:44:59 +0100

[Message part 1 (text/plain, inline)]

Instead of randomly breaking things, maybe it is time to rethink how
mozilla's libraries are handled. As I understand it, moving those
libraries to /usr/lib/mozilla is dictated by the fact they don't have a
SONAME (and we require a SONAME for libs in /usr/lib). But then, the
linker cannot find them anymore as they are not in one of its
directories.
There are at least 3 very important issues regarding these libraries :
1) libraries without SONAME
2) libraries in /usr/lib/mozilla
3) no stable ABI and nothing in the packaging to prevent breakage

1) could be solved by adding a SONAME. This would render us
binary-incompatible with upstream, but I don't think anyone is using
binary applications linked against mozilla today.
This would automatically solve 2), and 3) could be solved with putting
the libraries in a separate package.

The question is whether we really want to introduce that
incompatibility. Another possible solution would be to keep those
libraries without SONAME in /usr/lib like mozilla 1.2 did, but to use
virtual packages for dependencies, i.e. providing mozilla-1.3, and
making galeon/whatever depend on mozilla-1.3. This would solve 3) by the
means of the dependency system.

Convincing upstream to move to using SONAMEs would be nicer, of
course... :)

Please, don't keep the situation as is. If it is possible to provide a
smooth upgrade path for all of our users, why not doing it ?
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 184401-close@bugs.debian.org (full text, mbox, reply):

From: kitame@northeye.org

To: 184401-close@bugs.debian.org

Subject: NO

Date: Wed, 19 Mar 2003 17:13:39 +0900 (JST)

I think should not conflicts too.

Message #25 received at 184401@bugs.debian.org (full text, mbox, reply):

From: Brian Nelson <nelson@bignachos.com>

To: 184401@bugs.debian.org

Cc: control@bugs.debian.org

Subject: This still needs fixing

Date: Wed, 19 Mar 2003 01:22:30 -0800

reopen 184401
thanks

No, you still need to fix this.  This breaks the upgrade path from
woody.  For example, galeon in woody depends on mozilla-browser
(>=2:1.0.0), but obviously many versions of mozilla-browser will break
galeon despite satisfying that dependency.  That's completely
unacceptable.

Also, you've made a completely broken transition for GCC 3.2 as
documented here:

  http://people.debian.org/~rmurray/c++transition.html

  If you maintain a library written in C++:
    * add a `c102' to the end of the name of your .deb, eg
      libdb4.0++.deb -> libdb4.0++c102.deb. This is similar in spirit to
      the glibc transition adding `g' to the end of libraries.
    * You should not add a `c102' to your -dev package.
    * The exact placement of the `c102' can be tricky. It's not terribly
      important; the important thing is that the new package conflicts
      with the old and has a different name. Stylistically, we prefer to
      keep the `c102' adjacent to the soname number,
      e.g. libqt3c102-mt-odbc, but if your package ends in a ++, put the
      `c102' after that.
    * Add a Conflict with the non-`c102' version of the package.

Please consider Josselin's suggestions.  The current situation is
extremely broken and not suitable for release.

-- 
I had no feelings about it.  It was aloof and licked itself too much.
Like my cat Mr. Trotsky.

Message #32 received at 184401@bugs.debian.org (full text, mbox, reply):

From: Martin Schulze <joey@infodrom.org>

To: Debian Development <debian-devel@lists.debian.org>

Subject: Re: RFC: Handling of mozilla libraries

Date: Fri, 21 Mar 2003 08:59:11 +0100

Josselin Mouette wrote:
> Instead of randomly breaking things, maybe it is time to rethink how
> mozilla's libraries are handled. As I understand it, moving those
> libraries to /usr/lib/mozilla is dictated by the fact they don't have a
> SONAME (and we require a SONAME for libs in /usr/lib). But then, the
> linker cannot find them anymore as they are not in one of its
> directories.
> There are at least 3 very important issues regarding these libraries :
> 1) libraries without SONAME
> 2) libraries in /usr/lib/mozilla
> 3) no stable ABI and nothing in the packaging to prevent breakage
> 
> 1) could be solved by adding a SONAME. This would render us
> binary-incompatible with upstream, but I don't think anyone is using
> binary applications linked against mozilla today.
> This would automatically solve 2), and 3) could be solved with putting
> the libraries in a separate package.

Do these libraries have to be maintained by the regular linker?
If not, they could be load via dlopen() from any directory (like Apache
or PHP are handling their libraries).  If that's not an option, and
since Mozilla and Galeon are usually started via a wrapper script,
couldn't you add an LD_LIBRARY_PATH variable to its environment so
that the linker will find libraries in /usr/lib/mozilla as well?

Regards,

	Joey

-- 
Ten years and still binary compatible.  -- XFree86

Message #37 received at 184401@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <josselin.mouette@ens-lyon.org>

To: 184401@bugs.debian.org

Cc: Debian development list <debian-devel@lists.debian.org>

Subject: Re: RFC: Handling of mozilla libraries

Date: 21 Mar 2003 14:52:08 +0100

[Message part 1 (text/plain, inline)]

Le ven 21/03/2003 à 08:59, Martin Schulze a écrit :
> > 1) libraries without SONAME
> > 2) libraries in /usr/lib/mozilla
> > 3) no stable ABI and nothing in the packaging to prevent breakage

> Do these libraries have to be maintained by the regular linker?
> If not, they could be load via dlopen() from any directory (like Apache
> or PHP are handling their libraries).  If that's not an option, and
> since Mozilla and Galeon are usually started via a wrapper script,
> couldn't you add an LD_LIBRARY_PATH variable to its environment so
> that the linker will find libraries in /usr/lib/mozilla as well?

Opening those libraries with dlopen would probably require too many
changes in galeon, but using LD_LIBRARY_PATH would indeed work.

But that doesn't solve 3). We need some mechanism to provide clean
dependencies; a virtual package mozilla-1.X could do the trick, I've
been using this with hdf5 (which also constantly changes its ABI)
successfully for a while.
We also need a clean upgrade path from woody, which, as the situation in
woody is unclean, will require a conflict with older versions of
galeon/whatever.

Regards,
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 184401-close@bugs.debian.org (full text, mbox, reply):

From: Takuo KITAME <kitame@debian.org>

To: 184401-close@bugs.debian.org

Subject: Bug#184401: fixed in mozilla 2:1.3-4

Date: Wed, 26 Mar 2003 22:34:37 -0500

We believe that the bug you reported is fixed in the latest version of
mozilla, which is due to be installed in the Debian FTP archive:

libnspr-dev_1.3-4_i386.deb
  to pool/main/m/mozilla/libnspr-dev_1.3-4_i386.deb
libnspr4_1.3-4_i386.deb
  to pool/main/m/mozilla/libnspr4_1.3-4_i386.deb
libnss-dev_1.3-4_i386.deb
  to pool/main/m/mozilla/libnss-dev_1.3-4_i386.deb
libnss3_1.3-4_i386.deb
  to pool/main/m/mozilla/libnss3_1.3-4_i386.deb
mozilla-browser_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-browser_1.3-4_i386.deb
mozilla-chatzilla_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-chatzilla_1.3-4_i386.deb
mozilla-dev_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-dev_1.3-4_i386.deb
mozilla-dom-inspector_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-dom-inspector_1.3-4_i386.deb
mozilla-js-debugger_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-js-debugger_1.3-4_i386.deb
mozilla-mailnews_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-mailnews_1.3-4_i386.deb
mozilla-psm_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-psm_1.3-4_i386.deb
mozilla-xft_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-xft_1.3-4_i386.deb
mozilla-xmlterm_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla-xmlterm_1.3-4_i386.deb
mozilla_1.3-4.diff.gz
  to pool/main/m/mozilla/mozilla_1.3-4.diff.gz
mozilla_1.3-4.dsc
  to pool/main/m/mozilla/mozilla_1.3-4.dsc
mozilla_1.3-4_i386.deb
  to pool/main/m/mozilla/mozilla_1.3-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 184401@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Takuo KITAME <kitame@debian.org> (supplier of updated mozilla package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 22 Mar 2003 06:26:58 +0900
Source: mozilla
Binary: mozilla mozilla-dom-inspector mozilla-xmlterm libnspr4 mozilla-js-debugger mozilla-browser libnss3 libnspr-dev mozilla-chatzilla mozilla-psm mozilla-mailnews libnss-dev mozilla-xft mozilla-dev
Architecture: source i386
Version: 2:1.3-4
Distribution: unstable
Urgency: low
Maintainer: Takuo KITAME <kitame@debian.org>
Changed-By: Takuo KITAME <kitame@debian.org>
Description: 
 libnspr-dev - Netscape Portable Runtime library - development files
 libnspr4   - Netscape Portable Runtime Library
 libnss-dev - Network Security Service Libraries - development
 libnss3    - Network Security Service Libraries - runtime
 mozilla    - Mozilla Web Browser - dummy package
 mozilla-browser - Mozilla Web Browser - core and browser
 mozilla-chatzilla - Mozilla Web Browser - irc client
 mozilla-dev - Mozilla Web Browser - development files
 mozilla-dom-inspector - A tool for inspecting the DOM of pages in Mozilla.
 mozilla-js-debugger - JavaScript debugger for use with Mozilla
 mozilla-mailnews - Mozilla Web Browser - mail and news support
 mozilla-psm - Mozilla Web Browser - Personal Security Manager (PSM)
 mozilla-xft - Mozilla Web Browser - Xft support files
 mozilla-xmlterm - Mozilla Web Browser - XML enabled
Closes: 161759 181016 184401 185712 185780
Changes: 
 mozilla (2:1.3-4) unstable; urgency=low
 .
   * applied patch to fix unknown WM_CLASS (closes: #185780)
   * Depends on versioned dpkg (closes: #185712)
   * conflicts with galeon << 1.2.8-3, skipstone << 0.8.3-4 (closes: #184401)
   * remove unneeded /usr/lib/mozilla/component.reg (closes: #181016)
   * www-browser alternatives (closes: #161759)
Files: 
 9f499587fbc34f689c27b9b3976c209f 993 web optional mozilla_1.3-4.dsc
 28076b92d33fae86d9f899b528a1d6d5 890185 web optional mozilla_1.3-4.diff.gz
 716c5ca0704699f51c565426b9baf01b 1022 web optional mozilla_1.3-4_i386.deb
 a1e962959e7b1c5285fea612f6a67aca 10354130 web optional mozilla-browser_1.3-4_i386.deb
 2bc2a4ccf71f59dd8541304de2a835d1 131704 web optional mozilla-xft_1.3-4_i386.deb
 5cffa8ace0878e5d33982a0370766d2b 3007328 devel optional mozilla-dev_1.3-4_i386.deb
 49834c8d58d8d1b1ed91107387205b58 2089492 mail optional mozilla-mailnews_1.3-4_i386.deb
 83275844cd66503e1f69501444cc8712 147310 net optional mozilla-chatzilla_1.3-4_i386.deb
 940ecb6c1275839967de47e05440de1f 1982 x11 optional mozilla-xmlterm_1.3-4_i386.deb
 a3647f84fc43e605dee0156105b82c02 236354 web optional mozilla-psm_1.3-4_i386.deb
 0d45206fff589e592622b9467e7cc3c9 219812 web optional mozilla-dom-inspector_1.3-4_i386.deb
 ced7b9f089e307606b92bf39cdf2bb3c 233430 devel optional mozilla-js-debugger_1.3-4_i386.deb
 ff7f25deb6fd4b9cf0d0850db14e2531 116880 libs optional libnspr4_1.3-4_i386.deb
 398f8acaf572bca222e7b7ea6e7f1aff 166316 devel optional libnspr-dev_1.3-4_i386.deb
 e4223da059d41328a7265040804917d4 571570 libs optional libnss3_1.3-4_i386.deb
 c840359cd0323ff8588b1057e3e70d15 181688 devel optional libnss-dev_1.3-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+gm5JU+WZW1FVMwoRArQXAJ9lec6ezMfH2K/Ol0z+3cyXt5n4CwCfRKTf
kL1b0kBWpVcu3VPKrcXhNjc=
=ZlXc
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.