Debian Bug report logs - #758616
dpkg: support installing M-A:same packages with different binNMU version

Reply or subscribe to this bug.

Display info messages

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

From: Emilio Pozuelo Monfort <pochu@debian.org>

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

Subject: dpkg: support installing M-A:same packages with different binNMU version

Date: Tue, 19 Aug 2014 11:25:19 +0200

Package: dpkg
Version: 1.17.11
Severity: wishlist

(X-d-cc debian-release@)

Hi,

Currently M-A:same packages with different versions can't be co-installed.
That prevents packages that have been binNMUed in one architecture but not
another to be co-installed, e.g.

libfoo_1.1-1:i386
libfoo_1.1-1+b1:amd64

or

libfoo_1.1-1+b1:i386
libfoo_1.1-1+b2:amd64

Can't be co-installed.

This is problematic because packages get binNMU on a subset of architectures
very often (whenever it's not needed to binNMU them everywhere).

See e.g. #758527.

Emilio

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7
ii  libc6        2.19-7
ii  liblzma5     5.1.1alpha+20120614-2
ii  libselinux1  2.3-1
ii  tar          1.27.1-2
ii  zlib1g       1:1.2.8.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.6

-- no debconf information

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

From: Guillem Jover <guillem@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 758616@bugs.debian.org

Subject: Re: Bug#758616: dpkg: support installing M-A:same packages with different binNMU version

Date: Thu, 21 Aug 2014 00:21:41 +0200

Control: forcemerge 684625 -1

On Tue, 2014-08-19 at 11:25:19 +0200, Emilio Pozuelo Monfort wrote:
> Package: dpkg
> Version: 1.17.11
> Severity: wishlist

> Currently M-A:same packages with different versions can't be co-installed.
> That prevents packages that have been binNMUed in one architecture but not
> another to be co-installed, e.g.
> 
> libfoo_1.1-1:i386
> libfoo_1.1-1+b1:amd64
> 
> or
> 
> libfoo_1.1-1+b1:i386
> libfoo_1.1-1+b2:amd64
> 
> Can't be co-installed.
> 
> This is problematic because packages get binNMU on a subset of architectures
> very often (whenever it's not needed to binNMU them everywhere).
> 
> See e.g. #758527.

Yes, extensively discusssed in the mailing lists and already filed,
this is just a different side of the same assumptions. Merging.

Thanks,
Guillem

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

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Guillem Jover <guillem@debian.org>, 758616@bugs.debian.org

Subject: Re: Bug#758616: dpkg: support installing M-A:same packages with different binNMU version

Date: Fri, 22 Aug 2014 11:46:54 +0200

On 21/08/14 00:21, Guillem Jover wrote:
> Control: forcemerge 684625 -1
> 
> On Tue, 2014-08-19 at 11:25:19 +0200, Emilio Pozuelo Monfort wrote:
>> Package: dpkg
>> Version: 1.17.11
>> Severity: wishlist
> 
>> Currently M-A:same packages with different versions can't be co-installed.
>> That prevents packages that have been binNMUed in one architecture but not
>> another to be co-installed, e.g.
>>
>> libfoo_1.1-1:i386
>> libfoo_1.1-1+b1:amd64
>>
>> or
>>
>> libfoo_1.1-1+b1:i386
>> libfoo_1.1-1+b2:amd64
>>
>> Can't be co-installed.
>>
>> This is problematic because packages get binNMU on a subset of architectures
>> very often (whenever it's not needed to binNMU them everywhere).
>>
>> See e.g. #758527.
> 
> Yes, extensively discusssed in the mailing lists and already filed,
> this is just a different side of the same assumptions. Merging.

I saw #684625 but thought it was the old problem that installing +b1:i386 and
+b1:amd64 failed because of the different changelogs, problem that was solved /
worked around by adding binnmu changelog entries in separate changelogs.

Anyway, can you provide an update on this? Has there been any progress?

Thanks,
Emilio

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

From: Guillem Jover <guillem@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 758616@bugs.debian.org

Subject: Re: Bug#758616: dpkg: support installing M-A:same packages with different binNMU version

Date: Fri, 22 Aug 2014 15:57:13 +0200

Control: unmerge -1

On Fri, 2014-08-22 at 11:46:54 +0200, Emilio Pozuelo Monfort wrote:
> On 21/08/14 00:21, Guillem Jover wrote:
> > On Tue, 2014-08-19 at 11:25:19 +0200, Emilio Pozuelo Monfort wrote:
> >> Package: dpkg
> >> Version: 1.17.11
> >> Severity: wishlist
> > 
> >> Currently M-A:same packages with different versions can't be co-installed.
> >> That prevents packages that have been binNMUed in one architecture but not
> >> another to be co-installed, e.g.
> >>
> >> libfoo_1.1-1:i386
> >> libfoo_1.1-1+b1:amd64
> >>
> >> or
> >>
> >> libfoo_1.1-1+b1:i386
> >> libfoo_1.1-1+b2:amd64
> >>
> >> Can't be co-installed.
> >>
> >> This is problematic because packages get binNMU on a subset of architectures
> >> very often (whenever it's not needed to binNMU them everywhere).
> >>
> >> See e.g. #758527.
> > 
> > Yes, extensively discusssed in the mailing lists and already filed,
> > this is just a different side of the same assumptions. Merging.
> 
> I saw #684625 but thought it was the old problem that installing +b1:i386 and
> +b1:amd64 failed because of the different changelogs, problem that was solved /
> worked around by adding binnmu changelog entries in separate changelogs.

Right, and although both issues prevent co-installation, thinking about
it, that issue has not been fixed in dpkg itself, and they might require
different fixes. So, yeah I guess it does make sense to have in
different bug reports. Umerging.

> Anyway, can you provide an update on this? Has there been any progress?

I'm still not very comfortable with the possible implications of the
proposed solution (i.e. using the source version for comparison). I'll
be pondering about it, because I want to resolve most if not all
multi-arch issues in dpkg before the freeze, though.

Thanks,
Guillem

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

From: Wookey <wookey@wookware.org>

To: 758616@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: re: dpkg: support installing M-A:same packages with different binNMU version

Date: Fri, 28 Nov 2014 15:17:29 +0000

What is the current thinking on this for Jessie? I presume that at
this stage it is not going to be implemented so running lots of
binNMUs, or no-change sourceful upload to syncronise all arches is the
only fix available in that timeframe?

Does anyone know of problems that comparison of the source version
would actually cause? This seems to me to be the right way to deal
with this problem, but I don't claim any particular insight. Is the
worry just 'unforseen side-effects in complex code'? Syncronisation
with apt?

This issue is a real problem because of the way the binNMUs are
heavily using the build infrastructure for new port uploads (so after
adding two ports farily recently, lots of packages are out of sync).

There is now a handy jenkins job which tracks the size of the issue:
https://jenkins.debian.net/view/qa.debian.org/job/udd_jessie_multiarch_versionskew
(currently 266 source packages)

<aside>
Note that the non-unstable buildd overview pages ignore binNMUs when showing versions, so:
https://buildd.debian.org/status/package.php?p=xz-utils&suite=unstable  
shows binNMUs, but
https://buildd.debian.org/status/package.php?p=xz-utils&suite=jessie
doesn't.

You have to go to this page to find out what is really there:
https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=xz-utils

I presume this is a bug, it's certainly confusing.
</aside>

So, are the dpkg maintainers minded to try and fix this for Jessie?
(or should I schedule piles of rebuilds)
are the dpkg maintainers minded to fix this for Stretch?
or are there any other proposed fixes on the table?

I do think we need to do something about this.

Currently the binNMU for packages producing MA:same packages is
pointless as it just means that someone has to come along later and
rebuild all the other arches to match. Until this is fixed in dpkg (or
we invent some new mechanism for rebuilds without changing the version
number), packages which produce MA:same binarypkgs should always be
sourcefully uploaded.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

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

From: Guillem Jover <guillem@debian.org>

To: 758616@bugs.debian.org, debian-release@lists.debian.org

Subject: Re: Bug#758616: dpkg: support installing M-A:same packages with different binNMU version

Date: Fri, 28 Nov 2014 16:44:13 +0100

Hi!

On Fri, 2014-11-28 at 15:17:29 +0000, Wookey wrote:
> What is the current thinking on this for Jessie? I presume that at
> this stage it is not going to be implemented so running lots of
> binNMUs, or no-change sourceful upload to syncronise all arches is the
> only fix available in that timeframe?

I asked this on d-r last time it got brought up on d-d, but given the
lukewarm response, I didn't try anything further.

  <https://lists.debian.org/debian-release/2014/11/msg00019.html>

> Does anyone know of problems that comparison of the source version
> would actually cause? This seems to me to be the right way to deal
> with this problem, but I don't claim any particular insight. Is the
> worry just 'unforseen side-effects in complex code'? Syncronisation
> with apt?

I started implementing this, but posponed finishing it up for 1.18.x,
given the above response. If there is still interest I could propose
a patch. But it might end up being a non-minimal change.

As discussed some time ago on #debian-bootstrap, this just defers any
breakage to the reference counting code, so it just makes that
possible breakage be detectable later on. (The whole thing still seems
to me to be broken by design, but that ship sailed long ago.)

Thanks,
Guillem

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

From: Wookey <wookey@wookware.org>

To: 758616@bugs.debian.org

Subject: Fw: Re: binNMUs: please exercise some care

Date: Fri, 23 Oct 2015 13:51:17 +0100

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

This subject has come up again, and it seems that the release team
really would like to see the problem fixed in dpkg (or a statement
that it is not going to be, in which case a work-around in wb to
auto-bump the +bN number make sense). A dpkg fix (or replacing binNMUs
with sourceful uploads) seems much more like the right answer to me.

Thread at: https://lists.debian.org/debian-release/2015/10/msg00346.html

----- Forwarded message from Emilio Pozuelo Monfort <pochu@debian.org> -----

Date: Fri, 23 Oct 2015 11:49:44 +0200
From: Emilio Pozuelo Monfort <pochu@debian.org>
To: Thorsten Glaser <t.glaser@tarent.de>
Cc: debian-ports@lists.debian.org, debian-release
	<debian-release@lists.debian.org>, debian-wb-team
	<debian-wb-team@lists.debian.org>
Subject: Re: binNMUs: please exercise some care
X-Spam-Status: No, score=-5.5 required=4.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VERIFIED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,
	FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,LDO_WHITELIST,RCVD_IN_DNSWL_LOW
	autolearn=unavailable autolearn_force=no version=3.4.0
List-Id: <debian-wb-team.lists.debian.org>

On 23/10/15 11:20, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> 
>> I can go back to scheduling binNMUs for release architectures only, or for ANY
>> -x32. But I don't have the time to look at every architecture and determine
>> which one needs a binNMU and which one has already done it. Anyway if your
> 
> OK. In this case, scheduling them is probably better.

OK good to know.

>> buildds are fast enough that they already rebuilt things, then maybe rebuilding
>> them again is not such a big deal...
> 
> This is probably true for x32, yes, but I was concerned about
> M-A libraries not being coinstallable. For example, the harfbuzz
> library currently has one +b more than all others, making trouble
> for my desktop system (x32+i386 M-A). In that case, it wasn’t even
> because the rebuild was done twice, but, because another rebuild
> before the current (shared) one was necessary.
> 
> How about, scheduling them all at once, but using the same version
> number across arches when doing it (i.e. the largest)?

Again, that involves determining what that number is for each package...

Instead of all that manual work for every transition, you could ping #758616 and
try to get this solved at its root.

>> That wasn't me. But I'll try to spread the word about --extra-depends, as I
>> agree it's useful to avoid this. I didn't use it much in the past when I just
> 
> Okay, thanks a lot! Also, thanks for the response.

Cheers,
Emilio


----- End forwarded message -----
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

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

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

From: clubon@srv1.soldia.com

To: 758616@bugs.debian.org

Subject: Delivery Status Notification

Date: Sun, 12 Mar 2017 06:03:24 +0000

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

Dear Customer,

Please check the attachment for your item delivery details!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

08aVejV5AWlV8IXOAmgYMZa0HGu+0rcrcXTzsq/r0QBJISP/WpdtO2ua1DyisiOrLAbGWW7NT2d9
Uf6RbgAXqq496v8IoItvutMvQC4n8LDYB866SAnDv+4D2PYrQ7Ol9AeAz0zfEw2SibrfrLlhVKnG
eXW3cEs7VuXRNeizm34+lUmVyYSGgJJ4rAqJh38mU6LgXtps2nCEr8zGwcbcxAyxK8beKCRjOWk+
ti8gstMl3kVmKCm4KTuPiIBcRZdRoesuyPX7U0edt6ja9sLwFDFu7rTx+UaVlDgE6mNAyhhv2dCA
rmpIB53B3NuhvcTITKPoOyC8DYA3dvvisQ8yO5TBJVk0McGQJ7lf5BsTXmD7KGqEBHnm7z2iWA0U
smItcPvoTbUhdtl8sTLyqYi6b12lU1EZ0pH3A8GmNcMSP8AkCX6r81qe/eA8BDK5ielj1Y9wdM7+
IRzk85hgjBuEQDi5eEOnAfRWxDTMPQnbtxryOArbqcrLzv94/fBLm5z3Lb9JTij5KrBFquAo5Ps2
1zVx3tEY57tnYjSEySe58AUPWvS6HmzLLZpo+bKmJD9OPH5ZNE2at4n6vtkDC9bKrlqTpSEhpi+Q
QBr8Iys5+wLCxuU9DLwY1GYZUNm3z0zWUude4E6eMSSjYyoTVjdWO3Jz0HgmzTiwCIRSa2fVM7dZ
nCWH4uOBFZ7W5oIC5rtL3PIRYM7rCljDXhWkEaLaVfZkt/aic43R7JyXvnw8+K03tE4sFOFYhh4L
1nVKB2RINN0SwtIAgfSEMe8C8aPIRroXkmpXl6MDbDu2KMbgDQe8DNvkbdGjxZ+x8lcbXUVxB2nd
aNc9pf6jhtbh5Yuk+NfP7rpTTm1HpD0EhX152o/hcpMZi6vGVIRuFJVv+hLRjPPiWL0NRvBVHmzK
fwJBPAPiu/zazqgcNgFYCemMZkHcSISsPuF4BsVpPpPV6wKiVgvn97LPbcG/7TEQXqwk//ooANHG
fHJ2tiC0DZJN5AetYhBWqyvs/V3yCCPfWduL1/UpkLjHsDa6LIO0rqEs85JYvVjvDrYX8xZu1Xwc
x+HwoBznlWrK0WA/SKo+M4OV7yoqu6D7Oz86H14FWj2MTKK/3nk82bLeWuWS9NXX/aYqIyeEz6af
VDD81snKpeAnVs0li4BzqCe5+X2ysuUrOqe+KpVqE3fDCTEa9nAipE3kOCTe/jeF+I5Jj2zThYuG
brVr6I0vQAzGSYPaszlfj3sP2eJiR+f+IBNcGuW4ooECB3ulRuvGyS3E8ZpxB+Dcv/ZZ/uC/9IoD
PYXKOhswgl2ingmMLit/I0jFwwsoGHx+CHAMsKBoPQ==


-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Delivery-ID-KT8ZHRTE.zip (application/zip, attachment)]

Send a report that this bug log contains spam.