gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

[Debian Bug Importer]

Automatically imported from Debian bug report #333479 http://bugs.debian.org/333479

[Thomas Bushnell BSG (tb-becket)]

Ron <email address hidden> writes:

> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software
>
> Unless there is something big I am missing, gdk-imlib should
> certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

There is something big you are missing.

libpng2 is being removed from Debian. libpng12-0 is a suitable
replacement, source and binary compatible.

Old versions of gdk-imlib1 were linked against libpng2 (or libpng10-0,
which amount to the same thing). The new version of gdk-imlib1 is a
masquerade; it's really gdk-imlib11. Packages expecting gdk-imlib1
will work fine getting gdk-imlib11 instead, except for those that
independently link against libpng10-0 (or libpng2). Those will
encounter disasters, because both png's cannot be loaded into one
program simultaneously without problems.

So it was either recompile everything that uses gdk-imlib1, or
recompile everything that uses libpng2/libpng10-0. But the latter is
*already necessary*, because libpng2 is being removed from Debian.

Unstable is... unstable!

Packages that use libpng2 or libpng10-0 should be recompiled.

Thomas

[Steve Langasek (vorlon)]

On Wed, Oct 12, 2005 at 03:53:18PM +0930, Ron wrote:
> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software

> Unless there is something big I am missing,

Yes, there is. The old gdk-imlib1 depends on libpng2, and there are many
existing binaries, both in the archive and outside it, which depend directly
on both gdk-imlib1 and libpng2. The Conflicts is present to ensure that
users do not install combinations of packages on their systems that will
result in unusable, segfaulting applications, while allowing continued
installability of packages which depend on gdk-imlib1 without depending on
libpng2.

> gdk-imlib should certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

It doesn't. You're not forced to remove libpng2, you just don't get to keep
libpng2 *and* upgrade gdk-imlib1.

> Josselin: I see from #323354 that you are planning to kill
> off libpng2 soon in any case.

libpng2 is already gone from unstable. Any packages still depending on
libpng2 need to be rebuilt with libpng3 (libpng12-0) to be released with
etch.

> Where does this leave apps that still depend on gtk1? Will it be rebuilt
> to use png3, or something else?

These packages are already being rebuilt to use png3. This is why
gdk-imlib1 has this conflict.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Josselin Mouette (joss)]

Le mercredi 12 octobre 2005 à 15:53 +0930, Ron a écrit :
> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software

Software depending on a library is not "unrelated" software.

> Unless there is something big I am missing, gdk-imlib should
> certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

How so? It's just being removed from sid, and no upload of this package
has been made in the last 9 months.

> Josselin: I see from #323354 that you are planning to kill
> off libpng2 soon in any case. Where does this leave apps
> that still depend on gtk1? Will it be rebuilt to use png3,
> or something else? wx2.4 can build with png3 just fine,
> but I'm much less sure about how well it can be rebuilt with
> gtk2...

You should preferably rebuild it with gtk2, as the long-term plan is to
kill gtk1, but it's not going to happen anytime soon.

> That's not the only package that this (wrong IMO) change to
> gdk-imlib make uninstallable on my system though. Please
> fix this and/or advise of a transition plan.

You should just rebuild the package against gdk-imlib11, that's all.
That package is linked against libpng12, as libpng2/libpng10 has been
removed as well.

Regards,
--
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
   `- Debian GNU/Linux -- The power of freedom

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #333479 http://bugs.debian.org/333479

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 12 Oct 2005 15:53:18 +0930
From: Ron <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

Package: gdk-imlib1
Version: 1.9.14-22
Severity: critical
Justification: breaks unrelated software

Hi,

Unless there is something big I am missing, gdk-imlib should
certainly not take it upon itself to force the removal of
libpng2 and all its dependencies...

Josselin: I see from #323354 that you are planning to kill
off libpng2 soon in any case. Where does this leave apps
that still depend on gtk1? Will it be rebuilt to use png3,
or something else? wx2.4 can build with png3 just fine,
but I'm much less sure about how well it can be rebuilt with
gtk2...

That's not the only package that this (wrong IMO) change to
gdk-imlib make uninstallable on my system though. Please
fix this and/or advise of a transition plan.

thanks,
Ron

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gdk-imlib1 depends on:
ii imlib-base 1.9.14-21 Common files needed by the Imlib/G
ii libc6 2.3.5-6 GNU C Library: Shared libraries an
ii libglib1.2 1.2.10-10 The GLib library of C routines
ii libgtk1.2 1.2.10-18 The GIMP Toolkit set of widgets fo
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libpng10-0 1.0.18-1 PNG library, older version - runti
ii libtiff4 3.7.4-1 Tag Image File Format (TIFF) libra
ii libungif4g 4.1.3-3 shared library for GIF images (run
ii libx11-6 6.8.2.dfsg.1-8 X Window System protocol client li
ii libxext6 6.8.2.dfsg.1-8 X Window System miscellaneous exte
ii libxi6 6.8.2.dfsg.1-8 X Window System Input extension li
ii xlibs 6.8.2.dfsg.1-8 X Window System client libraries m
ii zlib1g 1:1.2.3-4 compression library - runtime

gdk-imlib1 recommends no packages.

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 11 Oct 2005 23:50:44 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Ron <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

Ron <email address hidden> writes:

> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software
>
> Unless there is something big I am missing, gdk-imlib should
> certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

There is something big you are missing.

libpng2 is being removed from Debian. libpng12-0 is a suitable
replacement, source and binary compatible.

Old versions of gdk-imlib1 were linked against libpng2 (or libpng10-0,
which amount to the same thing). The new version of gdk-imlib1 is a
masquerade; it's really gdk-imlib11. Packages expecting gdk-imlib1
will work fine getting gdk-imlib11 instead, except for those that
independently link against libpng10-0 (or libpng2). Those will
encounter disasters, because both png's cannot be loaded into one
program simultaneously without problems.

So it was either recompile everything that uses gdk-imlib1, or
recompile everything that uses libpng2/libpng10-0. But the latter is
*already necessary*, because libpng2 is being removed from Debian.

Unstable is... unstable!

Packages that use libpng2 or libpng10-0 should be recompiled.

Thomas

[Ron Lee (ron-debian)]

On Wed, Oct 12, 2005 at 12:30:31AM -0700, Steve Langasek wrote:
> On Wed, Oct 12, 2005 at 03:53:18PM +0930, Ron wrote:
> > Package: gdk-imlib1
> > Version: 1.9.14-22
> > Severity: critical
> > Justification: breaks unrelated software
>
> > Unless there is something big I am missing,
>
> Yes, there is. The old gdk-imlib1 depends on libpng2, and there are many
> existing binaries, both in the archive and outside it, which depend directly
> on both gdk-imlib1 and libpng2. The Conflicts is present to ensure that
> users do not install combinations of packages on their systems that will
> result in unusable, segfaulting applications, while allowing continued
> installability of packages which depend on gdk-imlib1 without depending on
> libpng2.

I'm aware of the trouble with mixing png versions (it's why wx2.4
reverted to libpng2/10 a couple of releases ago), but this still
seems like a strange place to hammer this nail from to me.

Why does png3/12 not declare this conflict now and let gdk-imlib
dependency on it do the rest?

> > gdk-imlib should certainly not take it upon itself to force the removal of
> > libpng2 and all its dependencies...
>
> It doesn't. You're not forced to remove libpng2, you just don't get to keep
> libpng2 *and* upgrade gdk-imlib1.

Well... it makes me glad I have nothing that directly depends on
gdk-imlib1, or my build machine would be losing tools I use while
this shakes out -- a situation that could have made timely updates
of my packages to suit a much more trying (and time consuming)
proposition.

> > Josselin: I see from #323354 that you are planning to kill
> > off libpng2 soon in any case.
>
> libpng2 is already gone from unstable.

Yes, I saw that was the case just after I fired this off.

> Any packages still depending on
> libpng2 need to be rebuilt with libpng3 (libpng12-0) to be released with
> etch.

Ack. I'll try to crank the handle for new wx2.4 packages tonight or
tomorrow then.

> > Where does this leave apps that still depend on gtk1? Will it be rebuilt
> > to use png3, or something else?
>
> These packages are already being rebuilt to use png3. This is why
> gdk-imlib1 has this conflict.

I'm still not sure I see how the latter automatically follows from
the former, but the song remains the same. I knew this was coming,
but if there was a note about it coming _now_, I must have missed it.

I can't say I'll be _unhappy_ to stop having to flip between the
two png-dev packages, depending on what I'm building for upload,
but I'm still missing something if this is the only/best way to
make this transition.

Done now though, so I guess I'll make the best of it...

cheers,
Ron

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 00:30:31 -0700
From: Steve Langasek <email address hidden>
To: Ron <email address hidden>, <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 12, 2005 at 03:53:18PM +0930, Ron wrote:
> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software

> Unless there is something big I am missing,

Yes, there is. The old gdk-imlib1 depends on libpng2, and there are many
existing binaries, both in the archive and outside it, which depend directly
on both gdk-imlib1 and libpng2. The Conflicts is present to ensure that
users do not install combinations of packages on their systems that will
result in unusable, segfaulting applications, while allowing continued
installability of packages which depend on gdk-imlib1 without depending on
libpng2.

> gdk-imlib should certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

It doesn't. You're not forced to remove libpng2, you just don't get to keep
libpng2 *and* upgrade gdk-imlib1.

> Josselin: I see from #323354 that you are planning to kill
> off libpng2 soon in any case.

libpng2 is already gone from unstable. Any packages still depending on
libpng2 need to be rebuilt with libpng3 (libpng12-0) to be released with
etch.

> Where does this leave apps that still depend on gtk1? Will it be rebuilt
> to use png3, or something else?

These packages are already being rebuilt to use png3. This is why
gdk-imlib1 has this conflict.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDTLuXKN6ufymYLloRAsqqAJ92vC5Tk/0XS+TD1tok6FTd1zNyFwCgq49x
/QEfzW8fB3UCnU6jgZUsBCM=
=yjhW
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--

[Ron Lee (ron-debian)]

On Wed, Oct 12, 2005 at 09:34:00AM +0200, Josselin Mouette wrote:
> Le mercredi 12 octobre 2005 ? 15:53 +0930, Ron a ?crit :
> > Package: gdk-imlib1
> > Version: 1.9.14-22
> > Severity: critical
> > Justification: breaks unrelated software
>
> Software depending on a library is not "unrelated" software.

It doesn't depend on gdk-imlib at all. Only png2/10 (and only
because gtk1 needed it to be so).

If this conflict came from png3/png-dev, I'd find it easier to
agree with that claim.

> > Unless there is something big I am missing, gdk-imlib should
> > certainly not take it upon itself to force the removal of
> > libpng2 and all its dependencies...
>
> How so? It's just being removed from sid, and no upload of this package
> has been made in the last 9 months.

Well the latter just makes it "stable" ;-) I guess I don't properly
understand the deep link between the png packages and the gdk-imlib
ones, as affects packages that don't care about gdk-imlib at all.

(the former I noticed after firing off this report)

> > Josselin: I see from #323354 that you are planning to kill
> > off libpng2 soon in any case. Where does this leave apps
> > that still depend on gtk1? Will it be rebuilt to use png3,
> > or something else? wx2.4 can build with png3 just fine,
> > but I'm much less sure about how well it can be rebuilt with
> > gtk2...
>
> You should preferably rebuild it with gtk2, as the long-term plan is to
> kill gtk1, but it's not going to happen anytime soon.

Yeah. wx2.6 is out, so the long term plan is to kill wx2.4, but
the same caveat applies.

> > That's not the only package that this (wrong IMO) change to
> > gdk-imlib make uninstallable on my system though. Please
> > fix this and/or advise of a transition plan.
>
> You should just rebuild the package against gdk-imlib11, that's all.
> That package is linked against libpng12, as libpng2/libpng10 has been
> removed as well.

In this case I just need to fix the build-dep from png10 -> png12,
(for the bits I'm responsible for) but I guess I missed the memo
that we were rolling on that this week. I'm not unhappy that it's
happening, just surprised at how...

thanks!
Ron

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 12 Oct 2005 09:34:00 +0200
From: Josselin Mouette <email address hidden>
To: Ron <email address hidden>, <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly
 conflict with libpng2

Le mercredi 12 octobre 2005 =E0 15:53 +0930, Ron a =E9crit :
> Package: gdk-imlib1
> Version: 1.9.14-22
> Severity: critical
> Justification: breaks unrelated software

Software depending on a library is not "unrelated" software.

> Unless there is something big I am missing, gdk-imlib should
> certainly not take it upon itself to force the removal of
> libpng2 and all its dependencies...

How so? It's just being removed from sid, and no upload of this package
has been made in the last 9 months.

> Josselin: I see from #323354 that you are planning to kill
> off libpng2 soon in any case. Where does this leave apps
> that still depend on gtk1? Will it be rebuilt to use png3,
> or something else? wx2.4 can build with png3 just fine,
> but I'm much less sure about how well it can be rebuilt with
> gtk2...

You should preferably rebuild it with gtk2, as the long-term plan is to
kill gtk1, but it's not going to happen anytime soon.

> That's not the only package that this (wrong IMO) change to
> gdk-imlib make uninstallable on my system though. Please
> fix this and/or advise of a transition plan.

You should just rebuild the package against gdk-imlib11, that's all.
That package is linked against libpng12, as libpng2/libpng10 has been
removed as well.

Regards,
--=20
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
   `- Debian GNU/Linux -- The power of freedom

[Josselin Mouette (joss)]

Le mercredi 12 octobre 2005 à 18:37 +0930, Ron a écrit :
> > You should just rebuild the package against gdk-imlib11, that's all.
> > That package is linked against libpng12, as libpng2/libpng10 has been
> > removed as well.
>
> In this case I just need to fix the build-dep from png10 -> png12,
> (for the bits I'm responsible for) but I guess I missed the memo
> that we were rolling on that this week. I'm not unhappy that it's
> happening, just surprised at how...

D'uh, I'm really sorry, I must have missed libwxgtk2.4 when filing bug
reports asking for the rebuild. Sorry about that.
--
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
   `- Debian GNU/Linux -- The power of freedom

[Steve Langasek (vorlon)]

On Wed, Oct 12, 2005 at 11:48:38AM +0200, Josselin Mouette wrote:
> Le mercredi 12 octobre 2005 à 18:37 +0930, Ron a écrit :
> > > You should just rebuild the package against gdk-imlib11, that's all.
> > > That package is linked against libpng12, as libpng2/libpng10 has been
> > > removed as well.

> > In this case I just need to fix the build-dep from png10 -> png12,
> > (for the bits I'm responsible for) but I guess I missed the memo
> > that we were rolling on that this week. I'm not unhappy that it's
> > happening, just surprised at how...

> D'uh, I'm really sorry, I must have missed libwxgtk2.4 when filing bug
> reports asking for the rebuild. Sorry about that.

There's actually no good reason for wxgtk2.4 to build-depend on libpng2-dev,
AFAICT, because *none* of the binary packages it builds depend on
libpng10-0. So I wonder why this build dependency is there...

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 18:22:26 +0930
From: Ron <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

On Wed, Oct 12, 2005 at 12:30:31AM -0700, Steve Langasek wrote:
> On Wed, Oct 12, 2005 at 03:53:18PM +0930, Ron wrote:
> > Package: gdk-imlib1
> > Version: 1.9.14-22
> > Severity: critical
> > Justification: breaks unrelated software
>
> > Unless there is something big I am missing,
>
> Yes, there is. The old gdk-imlib1 depends on libpng2, and there are many
> existing binaries, both in the archive and outside it, which depend directly
> on both gdk-imlib1 and libpng2. The Conflicts is present to ensure that
> users do not install combinations of packages on their systems that will
> result in unusable, segfaulting applications, while allowing continued
> installability of packages which depend on gdk-imlib1 without depending on
> libpng2.

I'm aware of the trouble with mixing png versions (it's why wx2.4
reverted to libpng2/10 a couple of releases ago), but this still
seems like a strange place to hammer this nail from to me.

Why does png3/12 not declare this conflict now and let gdk-imlib
dependency on it do the rest?

> > gdk-imlib should certainly not take it upon itself to force the removal of
> > libpng2 and all its dependencies...
>
> It doesn't. You're not forced to remove libpng2, you just don't get to keep
> libpng2 *and* upgrade gdk-imlib1.

Well... it makes me glad I have nothing that directly depends on
gdk-imlib1, or my build machine would be losing tools I use while
this shakes out -- a situation that could have made timely updates
of my packages to suit a much more trying (and time consuming)
proposition.

> > Josselin: I see from #323354 that you are planning to kill
> > off libpng2 soon in any case.
>
> libpng2 is already gone from unstable.

Yes, I saw that was the case just after I fired this off.

> Any packages still depending on
> libpng2 need to be rebuilt with libpng3 (libpng12-0) to be released with
> etch.

Ack. I'll try to crank the handle for new wx2.4 packages tonight or
tomorrow then.

> > Where does this leave apps that still depend on gtk1? Will it be rebuilt
> > to use png3, or something else?
>
> These packages are already being rebuilt to use png3. This is why
> gdk-imlib1 has this conflict.

I'm still not sure I see how the latter automatically follows from
the former, but the song remains the same. I knew this was coming,
but if there was a note about it coming _now_, I must have missed it.

I can't say I'll be _unhappy_ to stop having to flip between the
two png-dev packages, depending on what I'm building for upload,
but I'm still missing something if this is the only/best way to
make this transition.

Done now though, so I guess I'll make the best of it...

cheers,
Ron

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 18:37:18 +0930
From: Ron <email address hidden>
To: Josselin Mouette <email address hidden>, <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

On Wed, Oct 12, 2005 at 09:34:00AM +0200, Josselin Mouette wrote:
> Le mercredi 12 octobre 2005 ? 15:53 +0930, Ron a ?crit :
> > Package: gdk-imlib1
> > Version: 1.9.14-22
> > Severity: critical
> > Justification: breaks unrelated software
>
> Software depending on a library is not "unrelated" software.

It doesn't depend on gdk-imlib at all. Only png2/10 (and only
because gtk1 needed it to be so).

If this conflict came from png3/png-dev, I'd find it easier to
agree with that claim.

> > Unless there is something big I am missing, gdk-imlib should
> > certainly not take it upon itself to force the removal of
> > libpng2 and all its dependencies...
>
> How so? It's just being removed from sid, and no upload of this package
> has been made in the last 9 months.

Well the latter just makes it "stable" ;-) I guess I don't properly
understand the deep link between the png packages and the gdk-imlib
ones, as affects packages that don't care about gdk-imlib at all.

(the former I noticed after firing off this report)

> > Josselin: I see from #323354 that you are planning to kill
> > off libpng2 soon in any case. Where does this leave apps
> > that still depend on gtk1? Will it be rebuilt to use png3,
> > or something else? wx2.4 can build with png3 just fine,
> > but I'm much less sure about how well it can be rebuilt with
> > gtk2...
>
> You should preferably rebuild it with gtk2, as the long-term plan is to
> kill gtk1, but it's not going to happen anytime soon.

Yeah. wx2.6 is out, so the long term plan is to kill wx2.4, but
the same caveat applies.

> > That's not the only package that this (wrong IMO) change to
> > gdk-imlib make uninstallable on my system though. Please
> > fix this and/or advise of a transition plan.
>
> You should just rebuild the package against gdk-imlib11, that's all.
> That package is linked against libpng12, as libpng2/libpng10 has been
> removed as well.

In this case I just need to fix the build-dep from png10 -> png12,
(for the bits I'm responsible for) but I guess I missed the memo
that we were rolling on that this week. I'm not unhappy that it's
happening, just surprised at how...

thanks!
Ron

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 12 Oct 2005 11:48:38 +0200
From: Josselin Mouette <email address hidden>
To: Ron <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly
 conflict with libpng2

Le mercredi 12 octobre 2005 =E0 18:37 +0930, Ron a =E9crit :
> > You should just rebuild the package against gdk-imlib11, that's all.
> > That package is linked against libpng12, as libpng2/libpng10 has been
> > removed as well.
>=20
> In this case I just need to fix the build-dep from png10 -> png12,
> (for the bits I'm responsible for) but I guess I missed the memo
> that we were rolling on that this week. I'm not unhappy that it's
> happening, just surprised at how...

D'uh, I'm really sorry, I must have missed libwxgtk2.4 when filing bug
reports asking for the rebuild. Sorry about that.
--=20
 .''`. Josselin Mouette /\./\
: :' : <email address hidden>
`. `' <email address hidden>
   `- Debian GNU/Linux -- The power of freedom

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 03:20:34 -0700
From: Steve Langasek <email address hidden>
To: Josselin Mouette <email address hidden>, <email address hidden>
Cc: Ron <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

--JI+G0+mN8WmwPnOn
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 12, 2005 at 11:48:38AM +0200, Josselin Mouette wrote:
> Le mercredi 12 octobre 2005 =E0 18:37 +0930, Ron a =E9crit :
> > > You should just rebuild the package against gdk-imlib11, that's all.
> > > That package is linked against libpng12, as libpng2/libpng10 has been
> > > removed as well.

> > In this case I just need to fix the build-dep from png10 -> png12,
> > (for the bits I'm responsible for) but I guess I missed the memo
> > that we were rolling on that this week. I'm not unhappy that it's
> > happening, just surprised at how...

> D'uh, I'm really sorry, I must have missed libwxgtk2.4 when filing bug
> reports asking for the rebuild. Sorry about that.

There's actually no good reason for wxgtk2.4 to build-depend on libpng2-dev,
AFAICT, because *none* of the binary packages it builds depend on
libpng10-0. So I wonder why this build dependency is there...

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--JI+G0+mN8WmwPnOn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDTONyKN6ufymYLloRAtClAJ95V7KneHuwbID/uoX/4aSVbUhfnACeKXdl
+hXrppP6QkLunoT2RazFJlI=
=lPAm
-----END PGP SIGNATURE-----

--JI+G0+mN8WmwPnOn--

[Thomas Bushnell BSG (tb-becket)]

Ron <email address hidden> writes:

> In this case I just need to fix the build-dep from png10 -> png12,
> (for the bits I'm responsible for) but I guess I missed the memo
> that we were rolling on that this week. I'm not unhappy that it's
> happening, just surprised at how...

We actually rolled on that a long time ago. libpng10-dev was dropped
more than two weeks ago...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 10:25:57 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Ron <email address hidden>
Cc: <email address hidden>, Josselin Mouette <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2

Ron <email address hidden> writes:

> In this case I just need to fix the build-dep from png10 -> png12,
> (for the bits I'm responsible for) but I guess I missed the memo
> that we were rolling on that this week. I'm not unhappy that it's
> happening, just surprised at how...

We actually rolled on that a long time ago. libpng10-dev was dropped
more than two weeks ago...

[Tim Connors (tconnors)]

Thomas Bushnell BSG <email address hidden>
  Date: Tue, 11 Oct 2005 23:50:44 -0700:
> Ron <email address hidden> writes:
>
>> Package: gdk-imlib1
>> Version: 1.9.14-22
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> Unless there is something big I am missing, gdk-imlib should
>> certainly not take it upon itself to force the removal of
>> libpng2 and all its dependencies...
>
> There is something big you are missing.
>
> libpng2 is being removed from Debian. libpng12-0 is a suitable
> replacement, source and binary compatible.

Doesn't seem to be binary compatible at all. Shoot me for using a closed
sourced app, but xv doesn't like me symlinking /usr/lib/libpng.so.2 to
/usr/lib/libpng12.so, but copes fine with libpng10.so

For now, I've just manually copied the old libpng10.so over, and let dpkg
get rid of libpng10, since I don't think I am running any apps that run
both gdk-imlib1 and libpng2 simultaneously.

Why, instead of conflicting, couldn't you simply let apps that depend on
both to segfault, as you say, and then let users submit bugs to the app in
question that needs to be rebuilt anyway, instead of throwing out the baby
with the bathwater?

You seem to justify that this saves apps from outside debian from
breaking, but it breaks xv.

--
TimC
"The Write Many, Read Never drive. For those people that don't know
their system has a /dev/null already." -- Rik Steenwinkel, singing
the praises of 8mm Exabytes

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 23:02:15 +1100 (EST)
From: Tim Connors <email address hidden>
To: <email address hidden>
Subject: Re: Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict
 with libpng2

Thomas Bushnell BSG <email address hidden>
  Date: Tue, 11 Oct 2005 23:50:44 -0700:
> Ron <email address hidden> writes:
>
>> Package: gdk-imlib1
>> Version: 1.9.14-22
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> Unless there is something big I am missing, gdk-imlib should
>> certainly not take it upon itself to force the removal of
>> libpng2 and all its dependencies...
>
> There is something big you are missing.
>
> libpng2 is being removed from Debian. libpng12-0 is a suitable
> replacement, source and binary compatible.

Doesn't seem to be binary compatible at all. Shoot me for using a closed
sourced app, but xv doesn't like me symlinking /usr/lib/libpng.so.2 to
/usr/lib/libpng12.so, but copes fine with libpng10.so

For now, I've just manually copied the old libpng10.so over, and let dpkg
get rid of libpng10, since I don't think I am running any apps that run
both gdk-imlib1 and libpng2 simultaneously.

Why, instead of conflicting, couldn't you simply let apps that depend on
both to segfault, as you say, and then let users submit bugs to the app in
question that needs to be rebuilt anyway, instead of throwing out the baby
with the bathwater?

You seem to justify that this saves apps from outside debian from
breaking, but it breaks xv.

--
TimC
"The Write Many, Read Never drive. For those people that don't know
their system has a /dev/null already." -- Rik Steenwinkel, singing
the praises of 8mm Exabytes

[Carthik Sharma (carthik)]

Old Debian bug. Discussion at the Debian BTS seems to indicate that this can be closed.

[Albert Cahalan (acahalan)]

I lost all sorts of apps that Debian no longer packages.
I even lost penguineyes. Want to package it for me?

I guess it was wrong to rely on shared libraries. Debian
should use static linking. About the only thing stable
is the kernel system call interface.

Really, it's not cool to break old binaries.

[Thomas Bushnell BSG (tb-becket)]

"Albert Cahalan" <email address hidden> writes:

> I lost all sorts of apps that Debian no longer packages.
> I even lost penguineyes. Want to package it for me?
>
> I guess it was wrong to rely on shared libraries. Debian
> should use static linking. About the only thing stable
> is the kernel system call interface.
>
> Really, it's not cool to break old binaries.

I was not the one who made the decision to remove libpng2.

But without a clear bug report, I can't really say what the problem
is. If there is a specific bug, can you file it? What do you mean by
you "lost all sorts of apps"? I don't see how this long-closed bug
somehow lost apps.

Thomas

[Albert Cahalan (acahalan)]

On 5/21/06, Thomas Bushnell BSG <email address hidden> wrote:
> "Albert Cahalan" <email address hidden> writes:
>
> > I lost all sorts of apps that Debian no longer packages.
> > I even lost penguineyes. Want to package it for me?
> >
> > I guess it was wrong to rely on shared libraries. Debian
> > should use static linking. About the only thing stable
> > is the kernel system call interface.
> >
> > Really, it's not cool to break old binaries.
>
> I was not the one who made the decision to remove libpng2.
>
> But without a clear bug report, I can't really say what the problem
> is. If there is a specific bug, can you file it? What do you mean by
> you "lost all sorts of apps"? I don't see how this long-closed bug
> somehow lost apps.

Easy:

old stuff needs libpng2
new stuff depends on stuff that conflicts with libpng2
user needs the new stuff, and wants to keep the old stuff

Not upgrading would leave me with plenty of security holes,
so that isn't an option.

[Steve Langasek (vorlon)]

On Sun, May 21, 2006 at 09:33:47PM -0400, Albert Cahalan wrote:
> On 5/21/06, Thomas Bushnell BSG <email address hidden> wrote:
> >"Albert Cahalan" <email address hidden> writes:

> >> I lost all sorts of apps that Debian no longer packages.
> >> I even lost penguineyes. Want to package it for me?

> >> I guess it was wrong to rely on shared libraries. Debian
> >> should use static linking. About the only thing stable
> >> is the kernel system call interface.

> >> Really, it's not cool to break old binaries.

> >I was not the one who made the decision to remove libpng2.

> >But without a clear bug report, I can't really say what the problem
> >is. If there is a specific bug, can you file it? What do you mean by
> >you "lost all sorts of apps"? I don't see how this long-closed bug
> >somehow lost apps.

> Easy:

> old stuff needs libpng2
> new stuff depends on stuff that conflicts with libpng2
> user needs the new stuff, and wants to keep the old stuff

Your example for this was penguineyes. The penguineyes package in woody
depends only on gdk-imlib1, libc6, libglib1.2, libgtk1.2, xlibs, and
debconf; it should still be installable fine against etch. If you're seeing
evidence to the contrary, some apt output is probably going to be helpful
here.

> Not upgrading would leave me with plenty of security holes,
> so that isn't an option.

Anything that depends on libpng2 is not upgraded, and may also have security
holes.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Thomas Bushnell BSG (tb-becket)]

"Albert Cahalan" <email address hidden> writes:

> old stuff needs libpng2
> new stuff depends on stuff that conflicts with libpng2
> user needs the new stuff, and wants to keep the old stuff

Can you give a specific example please?