Re: bzip2 and multiarch transition

2014-07-31 Thread santiago
El 28/07/14 a las 21:10, Bastian Blank escribió:
 On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote:
  I guess you could offer lib32bz2 as a transitional package on the 32bit
  arch, depending on libbz2 of its own arch and vice versa for lib64?
 
 Since when does apt consider a:amd64 - a:i386 a valid upgrade path?
 
 The only reason to ship this in the future is to ease upgrades, but I
 don't see how this would work.

It wouldn't be an a:amd64 - b:i386 dependecy (not a:i386)?

As Dimitri says, it only works when i386/amd64 is enabled. The cleanest
option seems to be to just drop the lib32bz* packages.
For the record, I run some tests:

Case 1: i386 multiarch is not enable: apt does not consider to upgrade
it automatically, however apt-get install lib32bz2-1.0 understands the
dependency, but since it cannot satisfy it, it exits with error.
aptitude automatically considers to upgrade lib32bz2-1.0, but given the
unmet dependency, it removes the package as first solution.

Case 2: i386 mulitarch enabled: both apt-get and aptitude automatically
consider the upgrade and solve the dependencies.

I've found more issues trying to downgrade.

Thanks for your comments,

Santiago


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731145844.GA7155@nomada



Re: bzip2 and multiarch transition

2014-07-28 Thread Bastian Blank
On Mon, Jul 28, 2014 at 07:38:46AM +0200, santi...@debian.org wrote:
 So, to be sure, should I just drop the old lib{32,64}bz2*,
 without any transition mechanism? (no other package  depends on them
 now.)

If they are not referenced in the archive, nothing special needs to be
done.  And there is nothing you can do as package:arch dependencies does
not work properly for arch!=any/all.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, The City on the Edge of Forever, stardate 3134.0


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728054945.ga3...@mail.waldi.eu.org



Re: bzip2 and multiarch transition

2014-07-28 Thread Dimitri John Ledkov
On 28 July 2014 06:38,  santi...@debian.org wrote:
 Hi,

 (Please CC me when answering)

 I've just uploaded a new bzip2 revision and I think I need to revert a
 change. bzip2 used to build cross architecture lib{32,64}bz2* packages,
 but multiarch has obsoleted them. To stop building those packages (and
 close #736815), and to look for a smooth transition, I added
 conflicts/replace/provides control fields in the -1.0 and -dev packages.
 But I realized that those fields were wrong, at least useless (I also
 found [1]). So, to be sure, should I just drop the old lib{32,64}bz2*,
 without any transition mechanism? (no other package  depends on them
 now.)

Whilst not policy [*] compliant, you can keep old lib{32,64}bz2*
packages as empty  dummy transitional packages that depend on the new
multi-arch packages e.g. libbz2*:i386. That however, may be confusing
if one doesn't have multiarch for i386 enabled, for example, since
that package will not be available to be installed.

[*] policy used loosely here, multiarch wiki pages call for holding
back on using arch specific depends, however some maintainers are
starting to use it in the wild.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluixtfv48gjwi6oetxibmw9ndcrvo_yd+t8ul+ef0x1...@mail.gmail.com



Re: bzip2 and multiarch transition

2014-07-28 Thread Philipp Kern
On Mon, Jul 28, 2014 at 09:27:20AM +0100, Dimitri John Ledkov wrote:
 On 28 July 2014 06:38,  santi...@debian.org wrote:
  I've just uploaded a new bzip2 revision and I think I need to revert a
  change. bzip2 used to build cross architecture lib{32,64}bz2* packages,
  but multiarch has obsoleted them. To stop building those packages (and
  close #736815), and to look for a smooth transition, I added
  conflicts/replace/provides control fields in the -1.0 and -dev packages.
  But I realized that those fields were wrong, at least useless (I also
  found [1]). So, to be sure, should I just drop the old lib{32,64}bz2*,
  without any transition mechanism? (no other package  depends on them
  now.)
 Whilst not policy [*] compliant, you can keep old lib{32,64}bz2*
 packages as empty  dummy transitional packages that depend on the new
 multi-arch packages e.g. libbz2*:i386. That however, may be confusing
 if one doesn't have multiarch for i386 enabled, for example, since
 that package will not be available to be installed.

I guess you could offer lib32bz2 as a transitional package on the 32bit
arch, depending on libbz2 of its own arch and vice versa for lib64?

Kind regards
Philipp Kern


signature.asc
Description: Digital signature


Re: bzip2 and multiarch transition

2014-07-28 Thread Steve Langasek
On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote:
 On Mon, Jul 28, 2014 at 09:27:20AM +0100, Dimitri John Ledkov wrote:
  On 28 July 2014 06:38,  santi...@debian.org wrote:
   I've just uploaded a new bzip2 revision and I think I need to revert a
   change. bzip2 used to build cross architecture lib{32,64}bz2* packages,
   but multiarch has obsoleted them. To stop building those packages (and
   close #736815), and to look for a smooth transition, I added
   conflicts/replace/provides control fields in the -1.0 and -dev packages.
   But I realized that those fields were wrong, at least useless (I also
   found [1]). So, to be sure, should I just drop the old lib{32,64}bz2*,
   without any transition mechanism? (no other package  depends on them
   now.)
  Whilst not policy [*] compliant, you can keep old lib{32,64}bz2*
  packages as empty  dummy transitional packages that depend on the new
  multi-arch packages e.g. libbz2*:i386. That however, may be confusing
  if one doesn't have multiarch for i386 enabled, for example, since
  that package will not be available to be installed.

 I guess you could offer lib32bz2 as a transitional package on the 32bit
 arch, depending on libbz2 of its own arch and vice versa for lib64?

That would require an architecture change of the package on upgrade, which I
don't believe is going to go very smoothly.  It certainly wouldn't
automatically be considered an upgrade by apt.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: bzip2 and multiarch transition

2014-07-28 Thread Bastian Blank
On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote:
 I guess you could offer lib32bz2 as a transitional package on the 32bit
 arch, depending on libbz2 of its own arch and vice versa for lib64?

Since when does apt consider a:amd64 - a:i386 a valid upgrade path?

The only reason to ship this in the future is to ease upgrades, but I
don't see how this would work.

Bastian

-- 
Vulcans worship peace above all.
-- McCoy, Return to Tomorrow, stardate 4768.3


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728191044.ga5...@mail.waldi.eu.org



bzip2 and multiarch transition

2014-07-27 Thread santiago
Hi,

(Please CC me when answering)

I've just uploaded a new bzip2 revision and I think I need to revert a
change. bzip2 used to build cross architecture lib{32,64}bz2* packages,
but multiarch has obsoleted them. To stop building those packages (and
close #736815), and to look for a smooth transition, I added
conflicts/replace/provides control fields in the -1.0 and -dev packages.
But I realized that those fields were wrong, at least useless (I also
found [1]). So, to be sure, should I just drop the old lib{32,64}bz2*,
without any transition mechanism? (no other package  depends on them
now.)

Regards,

Santiago

[1] https://lists.debian.org/debian-devel/2012/03/msg00762.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728053514.GA12338@nomada