Debian Bug report logs - #535645
Wrongfull removal of ia32-libs-tools

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Goswin Brederlow <goswin-v-b@web.de>

Date: Sat, 4 Jul 2009 00:21:01 UTC

Severity: normal

Tags: moreinfo

Done: Don Armstrong <don@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian FTP Master <ftpmaster@ftp-master.debian.org>:
Bug#535645; Package ftp.debian.org. (Sat, 04 Jul 2009 00:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin Brederlow <goswin-v-b@web.de>:
New Bug report received and forwarded. Copy sent to Debian FTP Master <ftpmaster@ftp-master.debian.org>. (Sat, 04 Jul 2009 00:21:04 GMT) Full text and rfc822 format available.

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

From: Goswin Brederlow <goswin-v-b@web.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: RM: ia32-libs -- ROM; By popular demand.
Date: Sat, 04 Jul 2009 02:17:27 +0200
Package: ftp.debian.org
Severity: normal

Hi,

please remove the following 2 binary packages from unstable:

Package: ia32-libs
Version: 21
Filename: pool/main/i/ia32-libs-tools/ia32-libs_21_amd64.deb

Package: ia32-libs-gtk
Version: 21
Filename: pool/main/i/ia32-libs-tools/ia32-libs-gtk_21_amd64.deb

Mark Hymers might (or might not) later reupload the ia32-libs and
ia32-libs-gtk source packages again but meanwhile people shouldn't
install the above anymore.

MfG
	Goswin




Reply sent to Debian Archive Maintenance <ftpmaster@ftp-master.debian.org>:
You have taken responsibility. (Tue, 04 Aug 2009 22:00:08 GMT) Full text and rfc822 format available.

Notification sent to Goswin Brederlow <goswin-v-b@web.de>:
Bug acknowledged by developer. (Tue, 04 Aug 2009 22:00:08 GMT) Full text and rfc822 format available.

Message #10 received at 535645-close@bugs.debian.org (full text, mbox):

From: Debian Archive Maintenance <ftpmaster@ftp-master.debian.org>
To: 535645-close@bugs.debian.org
Cc: ia32-libs@packages.debian.org, ia32-libs@packages.qa.debian.org, ia32-libs-gtk@packages.debian.org, ia32-libs-gtk@packages.qa.debian.org
Subject: Bug#535645: fixed
Date: Tue, 04 Aug 2009 21:44:17 +0000
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

 ia32-libs |        2.7 | source
ia32-libs-dev |        2.7 | ia64
 lib32gcc1 | 1:4.3.1-9+ia32.libs.2.7 | ia64

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive (ftp-master.debian.org) and will not propagate to any
mirrors (ftp.debian.org included) until the next cron.daily run at the
earliest.

Packages are never removed from testing by hand.  Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems.

Bugs which have been reported against this package are not automatically
removed from the Bug Tracking System.  Please check all open bugs and
close them or re-assign them to another package if the removed package
was superseded by another one.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 535645@bugs.debian.org.

The full log for this bug can be viewed at http://bugs.debian.org/535645

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

Debian distribution maintenance software
pp.
Joerg Jaspert (the ftpmaster behind the curtain)




Message #11 received at 535645-close@bugs.debian.org (full text, mbox):

From: Debian Archive Maintenance <ftpmaster@ftp-master.debian.org>
To: 535645-close@bugs.debian.org
Cc: ia32-libs-tools@packages.debian.org, ia32-libs-tools@packages.qa.debian.org
Subject: Bug#535645: fixed
Date: Tue, 04 Aug 2009 21:50:16 +0000
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

ia32-apt-get |         22 | all
ia32-archive |         22 | all
ia32-libs-tools |         22 | source, amd64, i386, ia64

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive (ftp-master.debian.org) and will not propagate to any
mirrors (ftp.debian.org included) until the next cron.daily run at the
earliest.

Packages are never removed from testing by hand.  Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems.

Bugs which have been reported against this package are not automatically
removed from the Bug Tracking System.  Please check all open bugs and
close them or re-assign them to another package if the removed package
was superseded by another one.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 535645@bugs.debian.org.

The full log for this bug can be viewed at http://bugs.debian.org/535645

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

Debian distribution maintenance software
pp.
Joerg Jaspert (the ftpmaster behind the curtain)




Message #12 received at 535645-close@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Debian Archive Maintenance <ftpmaster@ftp-master.debian.org>
Cc: 535645-close@bugs.debian.org, ia32-libs-tools@packages.qa.debian.org, ia32-libs-tools@packages.debian.org
Subject: Re: [Pkg-ia32-libs-maintainers] Bug#535645: fixed
Date: Wed, 05 Aug 2009 10:54:02 +0200
Debian Archive Maintenance <ftpmaster@ftp-master.debian.org> writes:

> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
>
> ia32-apt-get |         22 | all
> ia32-archive |         22 | all
> ia32-libs-tools |         22 | source, amd64, i386, ia64
>

WTF did you do that for? The request was only for the transitional
packages ia32-lisb/ia32-libs-gtk that other DDs considered harmfull
and that ia32-libs-tools no longer did build to be removed.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Debian FTP Master <ftpmaster@ftp-master.debian.org>:
Bug#535645; Package ftp.debian.org. (Wed, 05 Aug 2009 13:42:41 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Romanchenko <paulaner@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian FTP Master <ftpmaster@ftp-master.debian.org>. (Wed, 05 Aug 2009 13:42:41 GMT) Full text and rfc822 format available.

Message #17 received at 535645@bugs.debian.org (full text, mbox):

From: Paul Romanchenko <paulaner@gmail.com>
To: 535645@bugs.debian.org
Subject: ia32 is broken now
Date: Wed, 5 Aug 2009 17:19:02 +0400
Removing ia32-apt-get renders some application unusable: skype, flashplugin...

/usr/lib/nspluginwrapper/i386/linux/npviewer.bin: error while loading
shared libraries: libuuid.so.1: cannot open shared object file: No
such file or directory

-- 
rmrfchik.




Bug 535645 cloned as bug 540489. Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Sat, 08 Aug 2009 11:57:01 GMT) Full text and rfc822 format available.

Changed Bug title to 'Wrongfull removal of ia32-libs-tools' from 'RM: ia32-libs -- ROM; By popular demand.' Request was from Goswin von Brederlow <goswin-v-b@web.de> to control@bugs.debian.org. (Sat, 08 Aug 2009 23:39:10 GMT) Full text and rfc822 format available.

Bug reassigned from package 'ftp.debian.org' to 'tech-ctte'. Request was from Goswin von Brederlow <goswin-v-b@web.de> to control@bugs.debian.org. (Sat, 08 Aug 2009 23:42:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 01:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 01:51:02 GMT) Full text and rfc822 format available.

Message #28 received at 535645@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: 535645@bugs.debian.org
Subject: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 09 Aug 2009 03:47:35 +0200
Dear CTTE,

I'm writing to you in the hope that you can facilitate resolving a
grievance I have with Joerg Jaspert in his roles as ftp-master and his
decision to remove ia32-libs-tools in the name of "The Project".

I started writing ia32-libs-tools 1 1/2 years ago based on my work as
ia32-libs maintainer and job experience with running Debian as Bi-Arch
on amd64. Joerg himself encouraged the developement of ia32-libs-tools
in the REJECTED mail of ia32-alsa-lib (see [1]) and while discussing
on irc. ia32-libs-tools has been in Debian for all but the initial
delay of packaing and NEW processing and has steadily improved to the
fully functional solution it is now.

According to popcon ia32-libs-tools has about 700 users and
ia32-apt-get about 500 (numbers now falling) and the users are now
left out in the cold with an inferior solution (ia32-libs) that only
covers a fraction of the features ia32-libs-tools provides (see
Background Information below). Rene Engelhard even requested a
backport to Lenny.

Ia32-libs-tools (all binary packages it builds) does not divert any
files of other packages, does not conflict/replace with any other
packages and does not interfere with the functionality of any other
packages even if installed. Specifically ia32-apt-get does not
interfere with the package management in any way unless the user
specifically invokes one of the ia32-... binaries. And even then
ia32-apt-get does not touch any of the internals of apt or dpkg. There
is no risk of the package management system getting broken.

There is also no (more) risk of 64bit packages unexpectetly being
upgraded to 32bit packages of a higher version. The existing package
had a debconfig option defaulting against this for some time and the
svn version has a even stronger protection against this. It is still
configurable and if a user wants to use a 32bit bash (or whatever) on
amd64 then he can configure that explicitly and it will work.

In short all the complaints raised in the flame fest on debian-devel
[2] have been addressed and removed from ia32-libs-tools. So I see no
reason "The Project" could have for removing ia32-libs-tools.

The source is fully licenced under GPL version 2 and all its bugs are
pending or wishlist like. None of the pending ones are above
important.

All the information I have about the removal is a conversation on IRC
and the removals.txt on ftp-master:

----------------------------------------------------------------------
14:25 < mrvn> Ganneff: ahh, you are awake. So will you accept ia32-libs-tools
        in its benign form it is now?
14:25 < Ganneff> *I* will not.
14:25 < mrvn> Ganneff: may I ask why?
14:26 < GyrosGeier> Ganneff, are there people left who can accept it and who
        might?
14:26 < GyrosGeier> (hypothetically speaking)
*silence*
----------------------------------------------------------------------

http://ftp-master.debian.org/removals.txt
=========================================================================
[Date: Tue, 04 Aug 2009 21:50:16 +0000] [ftpmaster: Joerg Jaspert]
Removed the following packages from unstable:

ia32-apt-get |         22 | all
ia32-archive |         22 | all
ia32-libs-tools |         22 | source, amd64, i386, ia64
Closed bugs: 535645

------------------- Reason -------------------
RoThe Project; Most idiotic breakage ever.
----------------------------------------------
=========================================================================


Please help me understand why Joerg just removed my package and
hopefully revert that decision.

What I'm asking for is that ia32-libs-tools is allowed to co-exist
with ia32-libs and ia32-libs-gtk as it has been for the year before
Jun 2009.

I'm not asking for ia32-libs or ia32-libs-gtk to be replaced. The only
reason ia32-libs-tools took them over was that ia32-libs was
unmaintainable, uninstallable and unmaintained for a year and as the
then maintainers we decided to abandon it. ia32-libs and ia32-libs-gtk
have a new maintainer now so they are his problem.

MfG
        Goswin



======================================================================

Background information
----------------------

After maintaining the ia32-libs packages for some time the
pkg-ia32-libs team came to the conclusion that there must be a better
way to do this. ia32-libs is fragile, needs constant work and uploads
and the sheer size makes frequently uploading new versions a problem
for the maintainer and the mirror network. There also is code (and
more importantly bugs) duplication between ia32-libs and ia32-libs-gtk
in Debian, ia32-libs-kde and ia32-libs-scim in Ubuntu and several more
ia32-libs-* packages build by users. So ia32-libs-tools was born.

ia32-libs-tools took the common elements of all the ia32-libs*
packages, converting an i386 debian package for use on amd64, and put
it in a tool anyone can Build-Depend on. So there is only one place
where bugs have to be fixed or features added.

The reason ia32-libs is fragile and needs constant watching is that
dependencies, conflicts, breaks are not considered for packages
included in ia32-libs. Every time a library changes its soname the
source breaks on update. Given that the sheer size was also a huge
problem the next step was splitting ia32-libs into multiple packages,
one package per source package that gets converted (95 of them,
*juck*), one binary package per binary package that gets
converted. That way all the existing package relationships could be
preserved and small individual packages could be uploaded when the
i386 package changes. This was rejected by ftp-master (see [1]).

In the REJECTED mail Joerg Jasper wrote:

| - How about you do not provide the ia32-foo packages yourself, but leave
|   that to the maintainers? Just provide the tools to *easily* create
|   them at build time. That would be the best way to go. It would enable
|   basically every package (where it makes sense) to have an ia32
|   version, do not double the source code needlessly, etc. Win win.

That is exactly what ia32-libs-tools provides. So in a way Joerg
himself suggested writing ia32-libs-tools even if that was after the
fact that I wrote it.

Unfortunately the DAK and wanna-build do not allow uploading a package
building libfoo_i386.deb, lib32foo_amd64.deb, lib32foo_ia64.deb on
i386, libfoo_amd64.deb on amd64 and libfoo_ia64.deb on ia64. So while
the tool would allow that the infrastructure does not. So creation at
build time is not possible.

Discussing this on irc resulted in the following points being made:

- The conversion process is completly automatic.
- Having converted debs in the archive is a huge waste of space.
- The conversion can be done on the users system just as well as
  during build time.
- Converting packages that already exist in the archive as needed by
  the user removes all the problems of missing security fixes, missing
  libraries, outdated versions, source/binary duplication, space and
  bandwith wasteage.

From that ia32-archive and ia32-apt-get were born.

Ia32-archive creates a local repository of converted packages that can
be used directly, exported via http, ftp or nfs or used to build CD
images that include 32bit support for amd64. Converting all the
packages included in ia32-libs and ia32-libs-gtk takes about 800MB
disk space though. 800MB that are completly wasted if the converted
packages are only for local use.

ia32-apt-get takes the process one step further doing a complete
on-the-fly conversion of packages as they are installed. That means
that if the user asks ia32-apt-get/ia32-aptitude to install
ia32-libfoo (32bit libfoo) it fetches the libfoo_i386.deb, converts
the control.tar.gz and data.tar.gz during unpacking and removes the
tempfiles when done. The only space required is enough temporary space
to unpack each package.

ia32-apt-get provides the following tools:

ia32-apt-get
ia32-aptitude
ia32-apt-cache
ia32-dpkg
ia32-dpkg-deb

All of them simple wrapper scripts that run the existing tools and do
some extra processing before or after the existing tool or just pass
an extra option or two.


Feature comparison:

        ia32-libs-tools			| ia32-libs
----------------------------------------| ------------------------------
Source: 69311 Bytes                     | 363171098 Bytes ia32-libs
                                        | 191042473 Bytes ia32-libs-gtk
                                        | 
Binary: 46142 Bytes ia32-libs-tools     |  29003858 Bytes ia32-libs
        18598 Bytes ia32-apt-get        |  12168602 Bytes ia32-libs-gtk
        11620 Bytes ia32-archive        | 
                                        | 
Suports:3975 libraries                  | 112+32 libraries
         315 binaries                   | 
        250+ tested and in use          | 
                                        | 
General:Honors Depends, Conflicts,      | Ignores them all
        Replaces, Breaks, Pre-Depends,  | 
        Provides                        | 
                                        | 
        Packages shlibs file converted  | Manual shlibs file with manual
        automatically preserving the    | versioning
        version requirements            |
                                        | 
        Instant (security) updates      | Needs manual intervention and
        for libraries                   | seperate upload for updates
                                        | 
        Allows installing i386 debs     | Needs repackaging of debs
        with full package relationship  | 
        checking                        | 
                                        | 
        Allows installing debs directly | Repacking means redistribution,
        from 3rd party apt repositories | not always legal to do so
        Example: skype                  | Example: skype
                                        | 
        Allows package maintainers to   | Special cases need to be added
        provide conversion hooks for    | in ia32-libs source by its
        special cases                   | maintainer
                                        | 
        Allows bit by bit conversion to | No upgrade path to multiarch.
        true multiarch as soon as       | User needs to purge ia32-libs
        support is added to apt, dpkg   | and all it reverse depends and
        and packages themself. Becomes  | reinstall software under
        less and less hackish the more  | multiarch. Mixtures will lead 
        multiarch is implemented        | to random version mismatches.


======================================================================

[1] http://lists.alioth.debian.org/pipermail/pkg-ia32-libs-maintainers/2008-April/000028.html

[2] http://lists.debian.org/debian-devel/2009/06/msg00902.html




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 02:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 02:18:02 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sat, 08 Aug 2009 19:15:13 -0700
Goswin von Brederlow <goswin-v-b@web.de> writes:

> I'm writing to you in the hope that you can facilitate resolving a
> grievance I have with Joerg Jaspert in his roles as ftp-master and his
> decision to remove ia32-libs-tools in the name of "The Project".

[...]

I'm not saying this means we should do nothing, just asking to help
understand the overall context better:  Does the debate over this package
become moot if Debian adopts full multiarch?  In other words, is this a
stop-gap solution while waiting for multiarch, or do you see it as having
an ongoing purpose even in a multiarch world?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 04:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 04:42:05 GMT) Full text and rfc822 format available.

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

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Russ Allbery <rra@debian.org>
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 09 Aug 2009 06:40:03 +0200
Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> I'm writing to you in the hope that you can facilitate resolving a
>> grievance I have with Joerg Jaspert in his roles as ftp-master and his
>> decision to remove ia32-libs-tools in the name of "The Project".
>
> [...]
>
> I'm not saying this means we should do nothing, just asking to help
> understand the overall context better:  Does the debate over this package
> become moot if Debian adopts full multiarch?  In other words, is this a
> stop-gap solution while waiting for multiarch, or do you see it as having
> an ongoing purpose even in a multiarch world?
>
> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

My plan is that it will be reduced to nothing as stages of multiarch
get implemented and finaly be removed. But multiarch will need time to
get there and ia32-apt-get probably will add extra value to it until
multiarch can enter round 2 after having been around for a full stable
release cycle.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 06:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 06:24:02 GMT) Full text and rfc822 format available.

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

From: Andreas Barth <aba@not.so.argh.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 535645@bugs.debian.org, guillem@debian.org, mhy@debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 08:20:51 +0200
* Goswin von Brederlow (goswin-v-b@web.de) [090809 06:44]:
> My plan is that it will be reduced to nothing as stages of multiarch
> get implemented and finaly be removed. But multiarch will need time to
> get there and ia32-apt-get probably will add extra value to it until
> multiarch can enter round 2 after having been around for a full stable
> release cycle.

Can you please say how you pkan the different stages of multiarch, and
when are they due? Is this plan coordinated with someone (release
team, ftp team, dpkg maintainer, ...)?

Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)?



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 15:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 15:51:08 GMT) Full text and rfc822 format available.

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

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Andreas Barth <aba@not.so.argh.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 535645@bugs.debian.org, guillem@debian.org, mhy@debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 09 Aug 2009 17:43:37 +0200
Andreas Barth <aba@not.so.argh.org> writes:

> * Goswin von Brederlow (goswin-v-b@web.de) [090809 06:44]:
>> My plan is that it will be reduced to nothing as stages of multiarch
>> get implemented and finaly be removed. But multiarch will need time to
>> get there and ia32-apt-get probably will add extra value to it until
>> multiarch can enter round 2 after having been around for a full stable
>> release cycle.
>
> Can you please say how you pkan the different stages of multiarch, and
> when are they due? Is this plan coordinated with someone (release
> team, ftp team, dpkg maintainer, ...)?

I don't think that is really relevant to the question of wether
ia32-libs-tools should be in the archive or not. Right now there is no
multiarch and right now ia32-libs-tools is a valuable tool for many
users. Even if there would be absolutely no plan to support multiarch
it would be just like ia32-libs, ia32-libs-gtk, dpkg-cross or apt-cross.

But here is the plan:

Implementing multiarch involves (among a million other details):

- Adding support to libapt to download binary-<arch>/Packages for
  multiple architectures and extending the sources.list format to
  include [arch=i386] syntax.
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536029

  If this is added then the ia32-apt-get, ia32-aptitude, ia32-synaptic
  wrappers can stop running multiple instances of apt-get to update
  the packages lists and use just Apt::Update::Post-Invoke. People
  can keep the wrappers or create an /etc/apt.conf.d/ia32-apt-get
  and use the plain versions.

- Adding support in libapt / dpkg to support package:arch and allowing
  libfoo:i386 and libfoo:amd64 to be coinstalled. Doesn't need
  handling of /usr/share/* nor handling the Multi-Arch field nor all
  the implicit package relationship magic multiarch involves.

  If this is added then instead of prefixing packages with ia32- for
  32bit packages can be suffixed with :i386 in package relationships.
  Appropriate Conflicts/Replaces get added by ia32-libs-tools and
  upgrades will replace all the ia32-* packages with *:i386.
  A stage 1 multiarch implementation would later simply upgrade
  libfoo:i386 1.2-3~24 (the ia32-libs-tools version) with libfoo:i386
  1.2-3 (the pristine Debian package). I can't imagine how the
  transition could be any smoother.

- Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in
  individual packages.

  If this is done (like experimental wine has just done) then
  ia32-libs-tools can stop moving files from /usr/lib to
  /usr/lib32.

- Introducing the Multi-Arch field in apt and dpkg.

  Ia32-libs-tools guesses what the Multi-Arch field should be
  depending on the package name (rename.list conffile contains
  patterns) and architecture (arch:all or arch:any). Library packages
  are then made (move libs from /urs/lib to /usr/lib32) to be
  coinstallable. "Multi-Arch: same" or "Multi-Arch: foreign" can then
  be added automatically.

- Using the Multi-Arch field in actual packages.

  Currently ia32-libs-tools has to do some guesswork (patterns in the
  rename.list conffile and architecture of packages) as to what the
  Multi-Arch field actually should be. With packages declaring their
  Multi-Arch type the guessing is replaced by knowledge.
  The renaming to ia32-foo or foo:i386 becomes more certain.

Those don't have to happen in any particular order and could happen
one by one, in pairs or all at once. But every time the apt and dpkg
maintainers add support for any one of the above some hack in
ia32-libs-tools can go away.

Once Stage1 of multiarch (as per the Ubuntu proposal) is completed,
and that is a release goal for squeeze, ia32-libs-tools will only
have to handle packages that didn't multiarchify in time for squeeze
(and there will certainly be some left) and -dev and -dbg packages that
need Stage2 of multiarch (which requires a stable release cycle).

When all packages (or enough that the difference doesn't matter) are
multiarchified and Stage2 has been completed then ia32-libs-tools will
have nothing left to do. All its features will be supported directly
by multiarch. The package becomes a NOP and obsolete.


As far as I'm concerned coordination will be through the BTS when I
write a patch for something, which means coordinated with the
respective maintainer. Or through the ML or irc when a maintainer has
a question about ia32-libs-tools. I'm not sure what the release team
or ftp team would have to do with ia32-libs-tools developement.
Whenever, however, by whomever multiarch will be implemented in apt,
dpkg and individual packages ia32-libs-tools can take advantage of it.

> Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)?

Make that "multiarch" (Tollef) and "multiarch" (Ubuntu). The
difference between the old and the new proposal is superficial. The
part that affects ia32-libs-tools is that "Multi-Arch: yes|no|unset"
became "Multi-Arch: same|foreign|unset".  From a coding point of view
it really makes no difference which of the two will be used and
whatever dpkg/apt will use I will use.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 16:19:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 16:19:15 GMT) Full text and rfc822 format available.

Message #53 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 535645@bugs.debian.org, guillem@debian.org, mhy@debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 18:12:22 +0200
* Goswin von Brederlow (goswin-v-b@web.de) [090809 17:43]:
> Andreas Barth <aba@not.so.argh.org> writes:
> > * Goswin von Brederlow (goswin-v-b@web.de) [090809 06:44]:
> >> My plan is that it will be reduced to nothing as stages of multiarch
> >> get implemented and finaly be removed. But multiarch will need time to
> >> get there and ia32-apt-get probably will add extra value to it until
> >> multiarch can enter round 2 after having been around for a full stable
> >> release cycle.
> >
> > Can you please say how you pkan the different stages of multiarch, and
> > when are they due? Is this plan coordinated with someone (release
> > team, ftp team, dpkg maintainer, ...)?
> 
> I don't think that is really relevant to the question of wether
> ia32-libs-tools should be in the archive or not. Right now there is no
> multiarch and right now ia32-libs-tools is a valuable tool for many
> users. Even if there would be absolutely no plan to support multiarch
> it would be just like ia32-libs, ia32-libs-gtk, dpkg-cross or apt-cross.

Well, e.g. if we would learn from the discussion that ia32-libs-tools
will be in the archive only till end of August anyways, I think our
decision is quite obvious.


[ resorted ]

> > Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)?
> 
> Make that "multiarch" (Tollef) and "multiarch" (Ubuntu). The
> difference between the old and the new proposal is superficial. The
> part that affects ia32-libs-tools is that "Multi-Arch: yes|no|unset"
> became "Multi-Arch: same|foreign|unset".  From a coding point of view
> it really makes no difference which of the two will be used and
> whatever dpkg/apt will use I will use.

So basically everything (except some values in apt) is the same? Did
Tollef agree to the steps below?



> - Adding support to libapt to download binary-<arch>/Packages for
>   multiple architectures and extending the sources.list format to
>   include [arch=i386] syntax.
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536029
> 
>   If this is added then the ia32-apt-get, ia32-aptitude, ia32-synaptic
>   wrappers can stop running multiple instances of apt-get to update
>   the packages lists and use just Apt::Update::Post-Invoke. People
>   can keep the wrappers or create an /etc/apt.conf.d/ia32-apt-get
>   and use the plain versions.

Is there any feedback from the apt maintainers on that? I cannot see
anything in the bug report.


> - Adding support in libapt / dpkg to support package:arch and allowing
>   libfoo:i386 and libfoo:amd64 to be coinstalled. Doesn't need
>   handling of /usr/share/* nor handling the Multi-Arch field nor all
>   the implicit package relationship magic multiarch involves.

No bug report yet I assume? Is this already discussed with the
appropriate maintainers?


> - Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in
>   individual packages.
> 
>   If this is done (like experimental wine has just done) then
>   ia32-libs-tools can stop moving files from /usr/lib to
>   /usr/lib32.

This sounds non-breaking to me. Has this been discussed somewhere
already? If so, how about doing "the usual" developer motivations,
like a (dynamic) page which libraries need to be changed, plus lintian
check? Do the glibc maintainers agree to change?



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 16:21:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 16:21:18 GMT) Full text and rfc822 format available.

Message #58 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: ftpmaster@debian.org, joerg@debian.org
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 18:15:27 +0200
Hi,

* Goswin von Brederlow (goswin-v-b@web.de) [090809 03:54]:
> I'm writing to you in the hope that you can facilitate resolving a
> grievance I have with Joerg Jaspert in his roles as ftp-master and his
> decision to remove ia32-libs-tools in the name of "The Project".


can we please get some input why this package was removed?


removals.txt only states:
[Date: Tue, 04 Aug 2009 21:50:16 +0000] [ftpmaster: Joerg Jaspert]
Removed the following packages from unstable:

ia32-apt-get |         22 | all
ia32-archive |         22 | all
ia32-libs-tools |         22 | source, amd64, i386, ia64
Closed bugs: 535645

------------------- Reason -------------------
RoThe Project; Most idiotic breakage ever.
----------------------------------------------


(rest of the mail is left for your information)



Thanks.



Cheers,
Andi


> I started writing ia32-libs-tools 1 1/2 years ago based on my work as
> ia32-libs maintainer and job experience with running Debian as Bi-Arch
> on amd64. Joerg himself encouraged the developement of ia32-libs-tools
> in the REJECTED mail of ia32-alsa-lib (see [1]) and while discussing
> on irc. ia32-libs-tools has been in Debian for all but the initial
> delay of packaing and NEW processing and has steadily improved to the
> fully functional solution it is now.
> 
> According to popcon ia32-libs-tools has about 700 users and
> ia32-apt-get about 500 (numbers now falling) and the users are now
> left out in the cold with an inferior solution (ia32-libs) that only
> covers a fraction of the features ia32-libs-tools provides (see
> Background Information below). Rene Engelhard even requested a
> backport to Lenny.
> 
> Ia32-libs-tools (all binary packages it builds) does not divert any
> files of other packages, does not conflict/replace with any other
> packages and does not interfere with the functionality of any other
> packages even if installed. Specifically ia32-apt-get does not
> interfere with the package management in any way unless the user
> specifically invokes one of the ia32-... binaries. And even then
> ia32-apt-get does not touch any of the internals of apt or dpkg. There
> is no risk of the package management system getting broken.
> 
> There is also no (more) risk of 64bit packages unexpectetly being
> upgraded to 32bit packages of a higher version. The existing package
> had a debconfig option defaulting against this for some time and the
> svn version has a even stronger protection against this. It is still
> configurable and if a user wants to use a 32bit bash (or whatever) on
> amd64 then he can configure that explicitly and it will work.
> 
> In short all the complaints raised in the flame fest on debian-devel
> [2] have been addressed and removed from ia32-libs-tools. So I see no
> reason "The Project" could have for removing ia32-libs-tools.
> 
> The source is fully licenced under GPL version 2 and all its bugs are
> pending or wishlist like. None of the pending ones are above
> important.
> 
> All the information I have about the removal is a conversation on IRC
> and the removals.txt on ftp-master:
> 
> ----------------------------------------------------------------------
> 14:25 < mrvn> Ganneff: ahh, you are awake. So will you accept ia32-libs-tools
>         in its benign form it is now?
> 14:25 < Ganneff> *I* will not.
> 14:25 < mrvn> Ganneff: may I ask why?
> 14:26 < GyrosGeier> Ganneff, are there people left who can accept it and who
>         might?
> 14:26 < GyrosGeier> (hypothetically speaking)
> *silence*
> ----------------------------------------------------------------------
> 
> http://ftp-master.debian.org/removals.txt
> =========================================================================
> [Date: Tue, 04 Aug 2009 21:50:16 +0000] [ftpmaster: Joerg Jaspert]
> Removed the following packages from unstable:
> 
> ia32-apt-get |         22 | all
> ia32-archive |         22 | all
> ia32-libs-tools |         22 | source, amd64, i386, ia64
> Closed bugs: 535645
> 
> ------------------- Reason -------------------
> RoThe Project; Most idiotic breakage ever.
> ----------------------------------------------
> =========================================================================
> 
> 
> Please help me understand why Joerg just removed my package and
> hopefully revert that decision.
> 
> What I'm asking for is that ia32-libs-tools is allowed to co-exist
> with ia32-libs and ia32-libs-gtk as it has been for the year before
> Jun 2009.
> 
> I'm not asking for ia32-libs or ia32-libs-gtk to be replaced. The only
> reason ia32-libs-tools took them over was that ia32-libs was
> unmaintainable, uninstallable and unmaintained for a year and as the
> then maintainers we decided to abandon it. ia32-libs and ia32-libs-gtk
> have a new maintainer now so they are his problem.
> 
> MfG
>         Goswin
> 
> 
> 
> ======================================================================
> 
> Background information
> ----------------------
> 
> After maintaining the ia32-libs packages for some time the
> pkg-ia32-libs team came to the conclusion that there must be a better
> way to do this. ia32-libs is fragile, needs constant work and uploads
> and the sheer size makes frequently uploading new versions a problem
> for the maintainer and the mirror network. There also is code (and
> more importantly bugs) duplication between ia32-libs and ia32-libs-gtk
> in Debian, ia32-libs-kde and ia32-libs-scim in Ubuntu and several more
> ia32-libs-* packages build by users. So ia32-libs-tools was born.
> 
> ia32-libs-tools took the common elements of all the ia32-libs*
> packages, converting an i386 debian package for use on amd64, and put
> it in a tool anyone can Build-Depend on. So there is only one place
> where bugs have to be fixed or features added.
> 
> The reason ia32-libs is fragile and needs constant watching is that
> dependencies, conflicts, breaks are not considered for packages
> included in ia32-libs. Every time a library changes its soname the
> source breaks on update. Given that the sheer size was also a huge
> problem the next step was splitting ia32-libs into multiple packages,
> one package per source package that gets converted (95 of them,
> *juck*), one binary package per binary package that gets
> converted. That way all the existing package relationships could be
> preserved and small individual packages could be uploaded when the
> i386 package changes. This was rejected by ftp-master (see [1]).
> 
> In the REJECTED mail Joerg Jasper wrote:
> 
> | - How about you do not provide the ia32-foo packages yourself, but leave
> |   that to the maintainers? Just provide the tools to *easily* create
> |   them at build time. That would be the best way to go. It would enable
> |   basically every package (where it makes sense) to have an ia32
> |   version, do not double the source code needlessly, etc. Win win.
> 
> That is exactly what ia32-libs-tools provides. So in a way Joerg
> himself suggested writing ia32-libs-tools even if that was after the
> fact that I wrote it.
> 
> Unfortunately the DAK and wanna-build do not allow uploading a package
> building libfoo_i386.deb, lib32foo_amd64.deb, lib32foo_ia64.deb on
> i386, libfoo_amd64.deb on amd64 and libfoo_ia64.deb on ia64. So while
> the tool would allow that the infrastructure does not. So creation at
> build time is not possible.
> 
> Discussing this on irc resulted in the following points being made:
> 
> - The conversion process is completly automatic.
> - Having converted debs in the archive is a huge waste of space.
> - The conversion can be done on the users system just as well as
>   during build time.
> - Converting packages that already exist in the archive as needed by
>   the user removes all the problems of missing security fixes, missing
>   libraries, outdated versions, source/binary duplication, space and
>   bandwith wasteage.
> 
> >From that ia32-archive and ia32-apt-get were born.
> 
> Ia32-archive creates a local repository of converted packages that can
> be used directly, exported via http, ftp or nfs or used to build CD
> images that include 32bit support for amd64. Converting all the
> packages included in ia32-libs and ia32-libs-gtk takes about 800MB
> disk space though. 800MB that are completly wasted if the converted
> packages are only for local use.
> 
> ia32-apt-get takes the process one step further doing a complete
> on-the-fly conversion of packages as they are installed. That means
> that if the user asks ia32-apt-get/ia32-aptitude to install
> ia32-libfoo (32bit libfoo) it fetches the libfoo_i386.deb, converts
> the control.tar.gz and data.tar.gz during unpacking and removes the
> tempfiles when done. The only space required is enough temporary space
> to unpack each package.
> 
> ia32-apt-get provides the following tools:
> 
> ia32-apt-get
> ia32-aptitude
> ia32-apt-cache
> ia32-dpkg
> ia32-dpkg-deb
> 
> All of them simple wrapper scripts that run the existing tools and do
> some extra processing before or after the existing tool or just pass
> an extra option or two.
> 
> 
> Feature comparison:
> 
>         ia32-libs-tools			| ia32-libs
> ----------------------------------------| ------------------------------
> Source: 69311 Bytes                     | 363171098 Bytes ia32-libs
>                                         | 191042473 Bytes ia32-libs-gtk
>                                         | 
> Binary: 46142 Bytes ia32-libs-tools     |  29003858 Bytes ia32-libs
>         18598 Bytes ia32-apt-get        |  12168602 Bytes ia32-libs-gtk
>         11620 Bytes ia32-archive        | 
>                                         | 
> Suports:3975 libraries                  | 112+32 libraries
>          315 binaries                   | 
>         250+ tested and in use          | 
>                                         | 
> General:Honors Depends, Conflicts,      | Ignores them all
>         Replaces, Breaks, Pre-Depends,  | 
>         Provides                        | 
>                                         | 
>         Packages shlibs file converted  | Manual shlibs file with manual
>         automatically preserving the    | versioning
>         version requirements            |
>                                         | 
>         Instant (security) updates      | Needs manual intervention and
>         for libraries                   | seperate upload for updates
>                                         | 
>         Allows installing i386 debs     | Needs repackaging of debs
>         with full package relationship  | 
>         checking                        | 
>                                         | 
>         Allows installing debs directly | Repacking means redistribution,
>         from 3rd party apt repositories | not always legal to do so
>         Example: skype                  | Example: skype
>                                         | 
>         Allows package maintainers to   | Special cases need to be added
>         provide conversion hooks for    | in ia32-libs source by its
>         special cases                   | maintainer
>                                         | 
>         Allows bit by bit conversion to | No upgrade path to multiarch.
>         true multiarch as soon as       | User needs to purge ia32-libs
>         support is added to apt, dpkg   | and all it reverse depends and
>         and packages themself. Becomes  | reinstall software under
>         less and less hackish the more  | multiarch. Mixtures will lead 
>         multiarch is implemented        | to random version mismatches.
> 
> 
> ======================================================================
> 
> [1] http://lists.alioth.debian.org/pipermail/pkg-ia32-libs-maintainers/2008-April/000028.html
> 
> [2] http://lists.debian.org/debian-devel/2009/06/msg00902.html
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 16:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 16:48:07 GMT) Full text and rfc822 format available.

Message #63 received at 535645@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Andreas Barth <aba@not.so.argh.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 535645@bugs.debian.org, guillem@debian.org, mhy@debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 09 Aug 2009 18:47:19 +0200
Andreas Barth <aba@not.so.argh.org> writes:

> * Goswin von Brederlow (goswin-v-b@web.de) [090809 17:43]:
>> Andreas Barth <aba@not.so.argh.org> writes:
>> > * Goswin von Brederlow (goswin-v-b@web.de) [090809 06:44]:
>> >> My plan is that it will be reduced to nothing as stages of multiarch
>> >> get implemented and finaly be removed. But multiarch will need time to
>> >> get there and ia32-apt-get probably will add extra value to it until
>> >> multiarch can enter round 2 after having been around for a full stable
>> >> release cycle.
>> >
>> > Can you please say how you pkan the different stages of multiarch, and
>> > when are they due? Is this plan coordinated with someone (release
>> > team, ftp team, dpkg maintainer, ...)?
>> 
>> I don't think that is really relevant to the question of wether
>> ia32-libs-tools should be in the archive or not. Right now there is no
>> multiarch and right now ia32-libs-tools is a valuable tool for many
>> users. Even if there would be absolutely no plan to support multiarch
>> it would be just like ia32-libs, ia32-libs-gtk, dpkg-cross or apt-cross.
>
> Well, e.g. if we would learn from the discussion that ia32-libs-tools
> will be in the archive only till end of August anyways, I think our
> decision is quite obvious.

Multiarch progress:

Core Toolchain support (binutils, gcc): Done after 5 years
Dpkg support: 0 lines of code in Debian
Apt  support: 0 lines of code in Debian
Aptitude support: 0 lines of code in Debian
Synaptic support: 0 lines of code in Debian
Cupt support: 0 lines of code in Debian
Support from the other 20k packages: 0 lines of code in Debian

Add to that: One stable release cycle needed for stage 2 support.

I would not hold my breath waiting even for only stage 1 support.


But lets assume that all gets done till the end of august. Then
ia32-libs-tools should still be in Debian so it can transition the
ia32-libfoo packages users have installed into the multiarch versions.

So no matter what timeline you assume ia32-libs-tools has its use.

> [ resorted ]
>
>> > Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)?
>> 
>> Make that "multiarch" (Tollef) and "multiarch" (Ubuntu). The
>> difference between the old and the new proposal is superficial. The
>> part that affects ia32-libs-tools is that "Multi-Arch: yes|no|unset"
>> became "Multi-Arch: same|foreign|unset".  From a coding point of view
>> it really makes no difference which of the two will be used and
>> whatever dpkg/apt will use I will use.
>
> So basically everything (except some values in apt) is the same? Did
> Tollef agree to the steps below?

From the Ubuntu Wiki:

Created: SteveLangasek
Contributors: SteveLangasek, HectorOron

I have no idea if Tollef is involved in the Ubuntu multiarch proposal
in any way. I know one of the dpkg maintainers is even if not listed
in the wiki.

The steps below are features that must be added to apt/dpkg in order
to implement the maultiarch proposal. It is how the proposal says
multiarch will work. So if Tollef (or anyone for that matter) agrees
with the multiarch proposal they already agreed to the steps below.

>> - Adding support to libapt to download binary-<arch>/Packages for
>>   multiple architectures and extending the sources.list format to
>>   include [arch=i386] syntax.
>>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536029
>> 
>>   If this is added then the ia32-apt-get, ia32-aptitude, ia32-synaptic
>>   wrappers can stop running multiple instances of apt-get to update
>>   the packages lists and use just Apt::Update::Post-Invoke. People
>>   can keep the wrappers or create an /etc/apt.conf.d/ia32-apt-get
>>   and use the plain versions.
>
> Is there any feedback from the apt maintainers on that? I cannot see
> anything in the bug report.

I talked with mvo on #debian-apt and he was open to including this
patch for the next experimental upload.

>> - Adding support in libapt / dpkg to support package:arch and allowing
>>   libfoo:i386 and libfoo:amd64 to be coinstalled. Doesn't need
>>   handling of /usr/share/* nor handling the Multi-Arch field nor all
>>   the implicit package relationship magic multiarch involves.
>
> No bug report yet I assume? Is this already discussed with the
> appropriate maintainers?

Ask Steve Langasek. The multiarch proposal requires it and it is not
the job of ia32-libs-tools to implement multiarch. I can just take
advantage of it whenever apt/dpkg include this part of multiarch. The
specific implementation (libfoo:i386, libfoo\i386, libfoo/i386,
libfoo[i386], i386-libfoo, whatever) also doesn't matter. The concept
is important in whatever syntax it will be implemented. That is also
true for all the other steps. The concept behind each step matters and
I can adjust to whatever implementation apt/dpkg will adapt.

>> - Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in
>>   individual packages.
>> 
>>   If this is done (like experimental wine has just done) then
>>   ia32-libs-tools can stop moving files from /usr/lib to
>>   /usr/lib32.
>
> This sounds non-breaking to me. Has this been discussed somewhere
> already? If so, how about doing "the usual" developer motivations,
> like a (dynamic) page which libraries need to be changed, plus lintian
> check? Do the glibc maintainers agree to change?

Eventual ALL library packages are supposed to change. As to which
"need" to change (first) depends on which libraries the user uses. The
ia32-libs and ia32-libs-gtk packages contain roughly the top 100
candidates. ia32-apt-get users use more.

The change is spelled out quite clearly in the multiarch proposal and
for a long time libc6 ships /etc/ld.so.conf.d/$(DEB_HOST_GNU_TYPE).conf 
containing:

  # Multiarch support
  /lib/$(DEB_HOST_GNU_TYPE)
  /usr/lib/$(DEB_HOST_GNU_TYPE)

So I assume they do agree. Iirc that was already supported in
old-stable. Certainly in stable.


But this really drifts off into an "implementing multiarch"
discussion, which this isn't about.

MfG
        Goswin





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 18:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 18:48:07 GMT) Full text and rfc822 format available.

Message #68 received at 535645@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 09 Aug 2009 11:46:38 -0700
Steve Langasek <vorlon@debian.org> writes:

> Per <http://lists.debian.org/debian-devel/2009/07/msg00121.html>,
> ia32-apt-get also imposes other obligations on a multiarch
> implementation, which no consensus has been reached on:
>
>   The upgrade path to multiarch is for the multiarch i386 deb to
>   Conflicts/Replaces: <package that contains the same files>. Which
>   means ia32-libs or ia32-libs-gtk for the old system or ia32-<package>
>   for the ia32-apt-get one. And again with ia32-apt-get there is a huge
>   advantage. As packages convert to multiarch they can be droped in
>   ia32-apt-get on a case by case basis and replaced by the multiarch
>   one. Meaning users don't have to wait for and update 200 packages in a
>   single step.
>
> So more than being a stop-gap, I think this tool is actively harmful to
> the rollout of multiarch.

The specific problem here, judging from the thread, is that these tools
create packages in the ia32-* namespace that aren't in the archive, and
people who then install those packages on their system will have trouble
with upgrades unless real multiarch packages add Conflicts with them?  But
the library maintainers both don't know that they exist, and would need to
add Conflicts on packages that have never been in the archive?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 19:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 19:36:03 GMT) Full text and rfc822 format available.

Message #73 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 21:32:29 +0200
* Steve Langasek (vorlon@debian.org) [090809 21:04]:
> The fallback would be to /assume/ they exist, and
> have each multiarch library package add Conflicts against the expected
> biarch package name; I don't accept that this is an appropriate burden to
> impose on individual library maintainers as part of the multiarch
> implementation, which should otherwise only require a small debian/rules
> change and a single Multi-Arch: yes field.

Can't that conflicts generation added in some debhelper-rule (same for
cdbs), which puts away the burden from most maintainers?



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 20:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 20:27:02 GMT) Full text and rfc822 format available.

Message #78 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 22:22:14 +0200
* Russ Allbery (rra@debian.org) [090809 21:49]:
> Hard to do that in debhelper.  debhelper doesn't introduce brand-new
> fields in debian/control; it just uses substvars.  cdbs could if run in
> the mode that regenerates debian/control, but of course that's not
> automatic.
> 
> Now, if the maintainer added the Conflicts field with the substvar, then
> yes, but it sounded like Steve doesn't think even that should be needed in
> most cases?

I have a few ugly ideas how to do it automatic in both cases even
without touching debian/control, but I agree that's not one should be
proud about.


It seems to me the question on ia32-libs-tools boils down to:

What is the "right" approach about going multiarch?


Obviously Steve disagrees with Goswin on the direct usage of
/usr/lib/$(DEB_HOST_GNU_TYPE) by packages. The same goes for the
question whether there should be a tool to automatically convert
normal packages "somehow" to pseudo-multiarch (or call that like you
want).


If the transition plan is like Goswin said here, I tend to consider
removing ia32-libs-tools to be wrong. My impression on that plan is
however that there is currently next to no buy-in from
dpkg/apt-maintainers, ftp* or anyone else who should be in the loop
for major changes. Looking at debian-devel during July shows quite
many heated discussions, which is usually a sign that a plan is not
accepted by the community at large.

If the transition plan is to avoid the conflicts (like put by Steve),
then the removal of ia32-libs-tools was necessary. I actually would be
interessted who is the driving that transition plan - a few names were
put up, but I haven't seen someone saying "I do it". Also the question
on buy-in should be answered here as well.


A few more (not so) random mails in that context:
http://lists.debian.org/debian-devel/2009/07/msg00093.html
http://lists.debian.org/debian-devel/2009/07/msg00060.html -
  ftp-masters on removal
http://lists.debian.org/debian-devel/2009/07/msg00120.html



The situation *currently* looks to me like there is no real decision
on how to do multiarch by the Debian project. A few things are already
getting decided (like naming of field values, or splitting of binaries
from glibc, see #330735), but as long as "who is driving the
transition", "how should the package layout be after the transition"
and "does ia32-libs-tools make the transition way harder" is
unanswered, I tend to consider that the correct decision for now was
to remove ia32-libs-tools, and - in case it is ensured it doesn't make
the multiarch life unnecessary hard - then to allow it to reenter
Debian as soon as that's ensured.




Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 09 Aug 2009 23:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 09 Aug 2009 23:18:02 GMT) Full text and rfc822 format available.

Message #83 received at 535645@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Andreas Barth <aba@not.so.argh.org>, 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Sun, 9 Aug 2009 16:15:59 -0700
On Sun, Aug 09, 2009 at 10:22:14PM +0200, Andreas Barth wrote:

> It seems to me the question on ia32-libs-tools boils down to:

> What is the "right" approach about going multiarch?

I don't agree that this is the right question, because ia32-libs-tools is
explicitly *not* part of multiarch.  It's a generalization of the existing
biarch kludge, and as such is the *opposite* of multiarch, notwithstanding
the fact that Goswin is planning a transition path to multiarch from
ia32-libs-tools.

The right question is if there's a compelling reason to override the ftp
master decision.  The rest would constitute design work on the part of this
committee, which is a) out of scope, b) a bad idea. :)

> Obviously Steve disagrees with Goswin on the direct usage of
> /usr/lib/$(DEB_HOST_GNU_TYPE) by packages. The same goes for the
> question whether there should be a tool to automatically convert
> normal packages "somehow" to pseudo-multiarch (or call that like you
> want).

I disagree with the direct usage of /usr/lib/<triplet> by any *biarch*
package: that is, I disapprove of use of these paths by any packages whose
Architecture doesn't match the triplet.

Since we will soon start to see packages making legitimate use of the
multiarch paths, that means none of these libraries should *ever* be
cross-installed via ia32-libs-tools, or else those kludged packages will
directly conflict with multiarch-enabled packages that are cross-installed.

> If the transition plan is like Goswin said here, I tend to consider
> removing ia32-libs-tools to be wrong. My impression on that plan is
> however that there is currently next to no buy-in from
> dpkg/apt-maintainers, ftp* or anyone else who should be in the loop
> for major changes. Looking at debian-devel during July shows quite
> many heated discussions, which is usually a sign that a plan is not
> accepted by the community at large.

The transition plan described is Goswin's own, not one that is the object of
a larger consensus.  My opinion is that the transition plan should consist
of not having ia32-libs-tools anywhere near the archive.

> If the transition plan is to avoid the conflicts (like put by Steve),
> then the removal of ia32-libs-tools was necessary. I actually would be
> interessted who is the driving that transition plan - a few names were
> put up, but I haven't seen someone saying "I do it". Also the question
> on buy-in should be answered here as well.

To what "transition plan" are you referring here?  Are you talking about
multiarch?  It seems so, but I'm not sure, as multiarch is not a "transition
plan", it's a design for laying out packages; and one which, if done right,
has so few transition requirements as to defy being called a "plan".

> The situation *currently* looks to me like there is no real decision
> on how to do multiarch by the Debian project. A few things are already
> getting decided (like naming of field values, or splitting of binaries
> from glibc, see #330735), but as long as "who is driving the
> transition", "how should the package layout be after the transition"

I thought this should have been clear from the mailing list discussions to
date, but as it's possible that you (and other members of the TC) have
overlooked something in the thread, or that I failed at making it clear, let
me clarify here.

I am currently driving the implementation of multiarch, in the sense that I
am investing time in pushing to make it happen; this will of course not
happen without agreement from affected maintainers, and I am indebted to a
number of others who are doing much of the work on implementation, but in
terms of taking overall responsibility for keeping multiarch moving forward,
that's exactly what I've been doing since about March of this year.  At
present, this effort is focused on the package manager definition and
implementation, as described here:

   https://wiki.ubuntu.com/MultiarchSpec

I have actively sought input from the maintainers of the affected packages,
and that spec reflects feedback from, among others: Guillem Jover (dpkg),
Aurelien Jarno (glibc), Michael Vogt (apt), Hector Oron (emdebian), Tollef
Fog Heen (author of various multiarch whitepapers), Colin Watson (Ubuntu),
and was the subject of a roundtable at DebConf9 (video available):

   https://penta.debconf.org/dc9_schedule/events/395.en.html

This plan does not require any changes to the division of packages compared
with what's currently required by Policy, if that's what you mean by
"package layout".  Or, if you mean filesystem layout, that part of the
design has been fixed for years.  We should probably have a single good
document we can refer to for this part, but I'm not currently aware of one
that's available; I think some of the original papers Tollef wrote on the
subject may have suffered bit rot.  Even so, I'm not aware of any disputes
over the target filesystem layout.

> and "does ia32-libs-tools make the transition way harder" is
> unanswered,

It makes it harder because there will be a large number of conflicting
biarch packages in the wild, which either the maintainers of each multiarch
library will need to declare Conflicts with, or they will be a source of bug
reports and confusion from users of this tool.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Mon, 10 Aug 2009 06:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 10 Aug 2009 06:51:02 GMT) Full text and rfc822 format available.

Message #88 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Mon, 10 Aug 2009 08:49:22 +0200
* Steve Langasek (vorlon@debian.org) [090810 01:19]:
> On Sun, Aug 09, 2009 at 10:22:14PM +0200, Andreas Barth wrote:

> > If the transition plan is like Goswin said here, I tend to consider
> > removing ia32-libs-tools to be wrong. My impression on that plan is
> > however that there is currently next to no buy-in from
> > dpkg/apt-maintainers, ftp* or anyone else who should be in the loop
> > for major changes. Looking at debian-devel during July shows quite
> > many heated discussions, which is usually a sign that a plan is not
> > accepted by the community at large.
> 
> The transition plan described is Goswin's own, not one that is the object of
> a larger consensus. 

That's why I said "the plan is not accepted by the community".

> My opinion is that the transition plan should consist
> of not having ia32-libs-tools anywhere near the archive.

Still, if the consensus *would* be that it is part, I'd be willing to
override the ftp-masters. Discussions don't make that probable.


> > If the transition plan is to avoid the conflicts (like put by Steve),
> > then the removal of ia32-libs-tools was necessary. I actually would be
> > interessted who is the driving that transition plan - a few names were
> > put up, but I haven't seen someone saying "I do it". Also the question
> > on buy-in should be answered here as well.
> 
> To what "transition plan" are you referring here?  Are you talking about
> multiarch?  It seems so, but I'm not sure, as multiarch is not a "transition
> plan", it's a design for laying out packages; and one which, if done right,
> has so few transition requirements as to defy being called a "plan".

replace the word "transition" by "implementation" then please. :)


> I am currently driving the implementation of multiarch, in the sense that I
> am investing time in pushing to make it happen; this will of course not
> happen without agreement from affected maintainers, and I am indebted to a
> number of others who are doing much of the work on implementation, but in
> terms of taking overall responsibility for keeping multiarch moving forward,
> that's exactly what I've been doing since about March of this year.

Good. Thanks. (I had the impression you were doing that, but I
couldn't remember to have read anywhere "I do that". Thanks for
clarification.)


[ buy-ins snapped ]

Now, Goswin has the choice to show a similar buy-in from core
maintainers in Debian. After private conversations I had with some, I
however doubt that this is possible.



Unless proven otherwise, I tend to the following conclusions:

1. The ftp-masters removed ia32-libs-tools with the following message
from the archive "RoThe Project; Most idiotic breakage ever.". About
45 mintes later (and not linked) they sent out this mail to
debian-devel http://lists.debian.org/debian-devel/2009/07/msg00060.html

2. The tech ctte was asked by Goswin to overrule the ftp-maintainer
decision to remove ia32-libs-tools.

3. After careful review, the transition plan to multiarch from Goswin
that includes usage of this tool doesn't seem to have broad support.

4. However, the implementation plan for multiarch from Steve has broad
support, with buy-in of key maintainers.

5. Steve is driving that implementation plan for some time, and he
explicitly disagrees (with stated reasons) with the presence of
ia32-libs-tools in the archive.

6. The way the decision of removal was communicated to Goswin seems
suboptimal to me. This however doesn't make the decision wrong.

7. Considering all these facts, I would recommend the tech ctte
to refuse to overrule the ftp-masters.



Comments?



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Mon, 10 Aug 2009 15:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 10 Aug 2009 15:39:02 GMT) Full text and rfc822 format available.

Message #93 received at 535645@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Mon, 10 Aug 2009 17:36:27 +0200
* Andreas Barth (aba@not.so.argh.org) [090810 08:54]:
> Unless proven otherwise, I tend to the following conclusions:
> 
> 1. The ftp-masters removed ia32-libs-tools with the following message
> from the archive "RoThe Project; Most idiotic breakage ever.". About
> 45 mintes later (and not linked) they sent out this mail to
> debian-devel http://lists.debian.org/debian-devel/2009/07/msg00060.html

Joerg took the chance to prove me wrong :)

[Date: Tue, 04 Aug 2009 21:50:16 +0000] [ftpmaster: Joerg Jaspert]
Removed the following packages from unstable:

ia32-apt-get |         22 | all
ia32-archive |         22 | all
ia32-libs-tools |         22 | source, amd64, i386, ia64


Mail sent out at
Date: Fri, 03 Jul 2009 00:31:36 +0200


So this was wrong. Doesn't influce the rest of the conclusions though.


Thanks Joerg for pointing that out.


Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Mon, 10 Aug 2009 20:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 10 Aug 2009 20:57:06 GMT) Full text and rfc822 format available.

Message #98 received at 535645@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 535645@bugs.debian.org
Cc: Goswin von Brederlow <goswin-v-b@web.de>
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Mon, 10 Aug 2009 13:50:01 -0700
Goswin von Brederlow <goswin-v-b@web.de> writes:

> So far I have only seen one reason stated clearly: Might hinder
> transition to multiarch. I think I have shown how I intend to handle
> that transition in ia32-libs-tools whenever and however Debian will do
> it. So far nobody has pointed out flaws in that plan.

Personally, the main thing that makes me uncomfortable with the
ia32-libs-tools approach from a design perspective is that it's
manipulating data that previously in Debian we've assumed is invarient.
In this thread some of the ideas discussed have involved rewriting the
Packages file so that uses via a different tool see different package
metadata, and creating Debian packages via a somewhat-official tool from
the main archive that do not appear in any of our package tracking systems
but which users may perceive as being part of Debian.

Even apart from the question of what specific problems people can
anticipate in advance and what solutions we can find for those problems,
both of those strike me as bad architectural approaches because they break
assumptions that users and software make about the data consistency of
Debian as a whole.  They're the kind of decisions that have a tendency to
cause unexpected and unanticipated problems in the future.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Mon, 10 Aug 2009 21:48:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 10 Aug 2009 21:48:17 GMT) Full text and rfc822 format available.

Message #103 received at 535645@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Russ Allbery <rra@debian.org>
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Mon, 10 Aug 2009 23:37:39 +0200
Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> So far I have only seen one reason stated clearly: Might hinder
>> transition to multiarch. I think I have shown how I intend to handle
>> that transition in ia32-libs-tools whenever and however Debian will do
>> it. So far nobody has pointed out flaws in that plan.
>
> Personally, the main thing that makes me uncomfortable with the
> ia32-libs-tools approach from a design perspective is that it's
> manipulating data that previously in Debian we've assumed is invarient.
> In this thread some of the ideas discussed have involved rewriting the
> Packages file so that uses via a different tool see different package

Yes. Only way to do it without having the packages duplicated in the
archive. Which as I might remind you ftp-master has REJECTED.

> metadata, and creating Debian packages via a somewhat-official tool from
> the main archive that do not appear in any of our package tracking systems
> but which users may perceive as being part of Debian.

The BTS situation can somewhat be remedied by providing
/usr/share/reportbug/ia32-<package>/control. Bugreports can be send to
either the original package or ia32-libs-tools with
that. If bugs are send to the original package then
/usr/share/reportbug/ia32-<package>/script can also add a note that
this package was converted by ia32-libs-tools and so on.

Everything reported via reportbug would be covered that way.

> Even apart from the question of what specific problems people can
> anticipate in advance and what solutions we can find for those problems,
> both of those strike me as bad architectural approaches because they break
> assumptions that users and software make about the data consistency of
> Debian as a whole.  They're the kind of decisions that have a tendency to
> cause unexpected and unanticipated problems in the future.

In the future we have multiarch. Aparently even for squeeze, or so is
the plan.

In the 1 1/2 years ia32-libs-tools has existed in Debian already there
has not been a flood of mysterious bugs and I think that track record
would hold. With multiarch to be in squeeze, we are talking only
about unstable users too. If the multiarch cabal holds their promises
then we are only talking some month to a year here.

> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Wed, 19 Aug 2009 02:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 19 Aug 2009 02:36:03 GMT) Full text and rfc822 format available.

Message #108 received at 535645@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>, 535645@bugs.debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Tue, 18 Aug 2009 19:33:54 -0700
tag 535645 moreinfo
thanks

On Sun, 09 Aug 2009, Goswin von Brederlow wrote:
> I'm writing to you in the hope that you can facilitate resolving a
> grievance I have with Joerg Jaspert in his roles as ftp-master and his
> decision to remove ia32-libs-tools in the name of "The Project".

[...]

> Please help me understand why Joerg just removed my package and
> hopefully revert that decision.

My understanding is that the CTTE was asked first to clarify the
reasoning surrounding the removal of ia32-libs-tools et al.; and only
take up discussions with regards to overriding the decision
afterwards.

Goswin: have the reasons for removal been clarified to your
satisfaction, or do you still want the CTTE to consider overriding the
ftpmasters? [If the latter, I'd suggest summarizing the discussion to
date as succinctly as possible, with the issues that lead to the
removal and your position on the severity and/or possible mitigation
and elmination of those issues. Otherwise, one of us will have to, and
that'll take longer.]


Don Armstrong

-- 
To steal ideas from one person is plagiarism; to steal from many is
research.
 -- Steven Wright

http://www.donarmstrong.com              http://rzlab.ucr.edu




Added tag(s) moreinfo. Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Wed, 19 Aug 2009 02:36:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Thu, 20 Aug 2009 12:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 20 Aug 2009 12:42:02 GMT) Full text and rfc822 format available.

Message #115 received at 535645@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: 535645@bugs.debian.org
Cc: debian-ctte@lists.debian.org
Subject: Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Date: Thu, 20 Aug 2009 14:31:35 +0200
Don Armstrong <don@debian.org> writes:

> tag 535645 moreinfo
> thanks
>
> On Sun, 09 Aug 2009, Goswin von Brederlow wrote:
>> I'm writing to you in the hope that you can facilitate resolving a
>> grievance I have with Joerg Jaspert in his roles as ftp-master and his
>> decision to remove ia32-libs-tools in the name of "The Project".
>
> [...]
>
>> Please help me understand why Joerg just removed my package and
>> hopefully revert that decision.
>
> My understanding is that the CTTE was asked first to clarify the
> reasoning surrounding the removal of ia32-libs-tools et al.; and only
> take up discussions with regards to overriding the decision
> afterwards.
>
> Goswin: have the reasons for removal been clarified to your
> satisfaction, or do you still want the CTTE to consider overriding the
> ftpmasters? [If the latter, I'd suggest summarizing the discussion to
> date as succinctly as possible, with the issues that lead to the
> removal and your position on the severity and/or possible mitigation
> and elmination of those issues. Otherwise, one of us will have to, and
> that'll take longer.]
>
>
> Don Armstrong

So far I have not seen a real clarification from Joerg, only from
Steve Langasek as head of the multiarch proposal. But I guess we can
take his silence as that the reasons Steve gave are the only ones.
With that information I would claim that the ia32-libs-tools issue is
a disagreement between a DD and a maintainer and that falls under the
scope of the Debian CTTE and not ftp-master. So ftp-master had no
right to take sides and just remove the package even if they have the
power to do so.

As far as I see it the situation is like this:

In short Steve fears that ia32-apt-get might impede the transition to
multiarch, which in the form users have installed NOW it does. That
fear is already a reality and removing ia32-apt-get has not and will
not undo the last 1 1/2 years of use of ia32-apt-get by many users.

On the other hand I have, based on the multiarch proposal from Steve,
detailed briefly [1] how ia32-apt-get will adapt to and actively use
multiarch features as they are being added to Debian. With those steps
ia32-apt-get users will transition smoothly to multiarch. And for
those users that stop using ia32-apt-get I proposed that the multiarch
capable dpkg will "Conflicts: ia32-abi", thereby causing the removal
of any ia32-* package left installed when multiarch comes. But that
requires that users did upgrade at least to version 22 of
ia32-apt-get. I believe not enough have had the chance before it was
removed. Specially note that this plan only requires one package, one
maintainer to do any work: dpkg has to add "Conflicts: ia32-abi" at
some point in the future. A not too difficult burden I believe.

I further pointed out the similarity to dpkg-cross, which has been in
Debian since 1997. The difference between ia32-libs-tools and
dpkg-cross are implementation details. They basically do the same and
if I wouldn't hate perl so much then I would have patched dpkg-cross
instead of writing ia32-libs-tools. So there is a 12 year precedence
for ia32-libs-tools like tools. There is a long history of doing what
ia32-libs-tools does, altering debs between download and installation,
even if for a slightly different goal.



So in conclusion I would ask the CTTE to suspend the ftp-master
removal and then mediate between Steve and me. I would ask you to
decide whether ia32-apt-get will be a problem for multiarch and wether
removing ia32-apt-get is the best course of action to clean up the
situation. Based on that ia32-apt-get either stays removed or I get
permission to upload it again.

The removal could also be temporarily reverted until Squeeze gets
frozen or released. By that time the multiarch proposal should be more
fleshed out and the situation should be clearer. The question could
then be revisited before ia32-libs-tools becomes part of a stable
release. If Steve really pulls it off to have multiarch functional in
squeeze then ia32-libs-tools might even be gone by itself making the
argument obsolete.

MfG
        Goswin

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645#48




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Thu, 20 Aug 2009 21:06:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jaime Ochoa Malagón <chptma@gmail.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 20 Aug 2009 21:06:13 GMT) Full text and rfc822 format available.

Message #120 received at 535645@bugs.debian.org (full text, mbox):

From: Jaime Ochoa Malagón <chptma@gmail.com>
To: 535645@bugs.debian.org, debian-ctte@lists.debian.org
Subject: I strongly suggest...
Date: Thu, 20 Aug 2009 15:57:24 -0500
[Message part 1 (text/plain, inline)]
Dear ctte,

We, the debian amd64 users should be able to pick our own poison, I really
prefer to have ia32-libs-tools because this work far more close to debian
way of package manage, the ia32-libs is an incomplete lazy solution with a
huge package that needs the maintainer to update a small part of it (any
library in the bundle) exposing us to security risks by example, any way,
the work done by Goswin has been proved and is working obviously needs
maintain to being better but Goswin is doing a great job.

Why loose a great package that's helps to use practically any ia32 program
just by a political reason?
The ftpmaster should complain about the package, even moving it to
experimental, but not, by any reason only remove it...

And finally if my memory is not failing Goswin was the maintainer of
ia32-libs and work in a better solution...

ia32-libs-tools is a great tool and I hope we can get it back...

-- 
Perhaps the depth of love can be calibrated by the number of different
selves that are actively involved in a given relationship.

Carl Sagan (Contact)

Jaime Ochoa Malagón
Arquitecto de Soluciones
Cel: +52 (55) 1021 0774
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Fri, 21 Aug 2009 00:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 00:03:05 GMT) Full text and rfc822 format available.

Message #125 received at 535645@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jaime Ochoa Malagón <chptma@gmail.com>
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: I strongly suggest...
Date: Thu, 20 Aug 2009 17:01:47 -0700
Jaime Ochoa Malagón <chptma@gmail.com> writes:

> We, the debian amd64 users should be able to pick our own poison, I
> really prefer to have ia32-libs-tools because this work far more close
> to debian way of package manage, the ia32-libs is an incomplete lazy
> solution with a huge package that needs the maintainer to update a small
> part of it (any library in the bundle) exposing us to security risks by
> example, any way, the work done by Goswin has been proved and is working
> obviously needs maintain to being better but Goswin is doing a great
> job.

> Why loose a great package that's helps to use practically any ia32
> program just by a political reason?

This sort of message is not likely to be helpful.  Technical committee
decisions are not a popularity contest, and there have been specific
objections to the design of the package previously discussed in this
thread.  It is not correct to state that the only issues here are
political.

If you have new information not previously mentioned in the thread to add,
please do, but statements of support without additional information should
not influence technical commitee decisions.

Please remember that the technical committee is not being asked whether or
not the design of ia32-libs-tools is useful, but rather to overturn a
project delegate decision.  This is a higher bar to meet.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Fri, 21 Aug 2009 00:18:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 00:18:07 GMT) Full text and rfc822 format available.

Message #130 received at 535645@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 535645@bugs.debian.org, ftpmaster@ftp-master.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Thu, 20 Aug 2009 17:17:26 -0700
Bdale Garbee <bdale@gag.com> writes:
> On Thu, 2009-08-20 at 07:35 -0700, Steve Langasek wrote:

>> I would have no objections to the ftp team allowing ia32-apt-get back
>> into the archive, but I'm going to vote against overriding them; and
>> barring a motion from another TC member to override the ftp team, I
>> don't intend to spend more energy on this thread.  If you want to see
>> this package back in the archive, I recommend that you persuade the ftp
>> team that /their/ concerns with the package are addressed.

> I agree that this is the most reasonable approach to resolution.  I,
> too, am unwilling to override the existing ftp-master decision in this
> matter based on the discussion so far in this thread.

Here's a summary of where I'm at on this issue.

* Multiarch is the correct solution to the problem, and the sooner that we
  get to multiarch, the better.  Everyone generally agrees on this.  The
  debate is essentially over what short-term cludge we want to use to
  support 32-bit binaries on amd64 platforms until we get multiarch.

* Both ia32-libs and ia32-libs-tools are ugly solutions, but in different
  ways.

* The ia32-apt-get architecture, involving meddling with package metadata
  and rebuilding packages into its own namespace that aren't in the Debian
  archive, breaks some invariants about Debian package metadata and
  violates intended abstraction layers in ways that I find disturbing.
  It's a solution that sets off warning bells for me.  I think the
  problems and pitfalls of ia32-libs are better-understood and less
  fundamental.

* ia32-libs is not a new bandaid.  It's the one that we've been living
  with for some time.  Its problems, which are significant, are at least
  problems that we've already dealt with and have for some time, and the
  relevant people in Debian know how to work around them or deal with them
  as needed.  This is not true of ia32-libs-tools.

* The dpkg-cross comparison isn't entirely relevant.  dpkg-cross is a tool
  for experts in a narrow scope around an unusual use of Debian.
  ia32-libs-tools is much more likely to be used by naive users who are
  trying to get third-party commercial software such as Flash players to
  work.  The dpkg-cross users can be presumed to have a better idea what
  they're doing, and to be aware that they're doing something strange that
  they may have to take apart and put back together again as the rest of
  Debian moves forward.  ia32-libs-tools is more likely to reach an
  unsophisticated mass user base.

The best solution is clearly to finish multiarch and remove the need to do
anything in this area.  In the meantime, I think it's reasonable for
ftpmaster to pick the poison that they want to live with between the two
ugly solutions that have been put forward.  If they think that ia32-libs
is less broken in the short term than ia32-libs-tools, I don't want to
argue with them, and I don't see a lot of compelling need to have both of
them.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Fri, 21 Aug 2009 16:48:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 16:48:28 GMT) Full text and rfc822 format available.

Message #135 received at 535645@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: debian-ctte@lists.debian.org
Cc: 535645@bugs.debian.org
Subject: ia32-libs-tools situation summary
Date: Fri, 21 Aug 2009 18:24:48 +0200
Hi,

To recap the current issue: The ia32-libs-tools package has been
removed from Debian, and I am uncertain of the technical reasons that
underlie this removal. While no such reasons have been communicated to
me, here are some of the speculations on them.

Possible reasons for its removal:

- ia32-libs-tools hinders implementing multiarch

While this was true in older versions the first steps to allow a
smooth transition for multiarch had already been taken. The multiarch
proposal is still slightly in flux, and as yet is unimplemented. But
going by the proposal as it stands so far there is a plan in place
that will allow a smooth transition. The ia32-* packages will be
replaced by multiarch packages as they become available or be removed
all in one go if the user chooses not to follow the upgrade path.

There is also a fall-back in place in case things don't work out where
all ia32-* will be removed when multiarch comes. That would do
automatically what users have to do manually now to undo their use of
ia32-libs-tools. So there is a smooth transition plan and a safety
net.

- we have ia32-libs, we don't need a second method for 32bit support

Ia32-libs does not and more importantly can not fully replace
ia32-libs-tools. It will always lack security fixes, have mismatched
versions of packages, lack unstable packages and lack libraries
altogether that users need to run their programs. It also provides no
way to install and upgrade binary packages like skye, biblepro and
many more. Ia32-libs-tools is not just another ia32-libs. It is
better, more flexible and it is more.

- nobody uses ia32-libs-tools and we want to prevent anyone from
  starting now so they don't end up in a dead end when multiarch comes

Popcon showed nearly 500 users. People have been using ia32-libs-tools
for 1 1/2 years now and many ia32-* packages are already installed on
users systems. By removing ia32-libs-tools users are stuck in an
artificial dead end with no way back or forward. They now have to
purge all ia32-* packages and binaries that depend on them and then
use a completely different method to get them back (e.g. setup a
chroot).  Ia32-libs-tools itself will provide the way forward and will
bring users back to "pure" Debian by transitioning into multiarch when
that becomes reality.

- the transformation in ia32-libs-tools breaks things

The transformation in ia32-libs-tools is a combination of what
ia32-libs does during build and dpkg-cross/apt-cross does during
installation. Both are well understood. On top of that ia32-libs-tools
has been in use for 1 1/2 years. The combination of both methods has
proven to work reliable for many uploads of new libraries and the
limitations and pitfalls are know well understood.

What did break was the maintainer scripts in version 18 and has been
fixed or reverted in subsequent uploads. That never affected the
transformation of packages and having been solved is no removal reason
either.

- maintainers have to support ia32-libs-tools as well as ia32-libs and
  multiarch

Anything that works in ia32-libs or multiarch (as far as the proposed
specs say) works in ia32-libs-tools. Ia32-libs-tools also fixes
several issues ia32-libs has all without the need for any maintainer
to lift a finger. Ia32-libs-tools does not force extra work onto
maintainers. On the other hand ia32-libs-tools allows maintainers who
are interested to pitch in and provide a helper script where
necessary. Normally ia32-libs-tools provides all the necessary
helpers but if a maintainer wishes to opt-in and get a closer control
over the transformation of his package then ia32-libs-tools is
prepared for that.

- bug reports will go to the wrong place

Firstly that hasn't happened yet, in 1 1/2 years of use, in any
noticeable quantity. Overall I think 3 bugs were filed on the wrong
package during that time. But it is a valid point and to address the
issue I am prepared to set the Maintainer of converted packages to me
and add a /usr/share/reportbug/<package>/control file containing
"Submit-As: ia32-libs-tools" in every converted package.



If there is a technical reason for the removal of ia32-libs-tools, it
has not been communicated. I think people working on packages have the
right to be told why the packages are unfit for the project, if for no
other reason than for the mistake to be not repeated, and to ensure
that there is indeed a technical reason for removal.

I ask the technical Committee to ascertain that such a technical
reason exists, and to communicate this to the rest of the project, or,
failing such a technical reason, to overturn the ftp-masters decision
to remove it.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Fri, 21 Aug 2009 16:54:42 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 16:54:42 GMT) Full text and rfc822 format available.

Message #140 received at 535645@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 535645@bugs.debian.org
Subject: Re: Bug#535645: I strongly suggest...
Date: Fri, 21 Aug 2009 09:41:13 -0700
Goswin von Brederlow <goswin-v-b@web.de> writes:

> Correct. There so far is no stated issue with ia32-libs-tools at all. So
> far there has only been speculation, as Steve pointed out.

I do not agree with this statement.

> On the other hand I think point 4 of the social contract is relevant
> here:

This is even less helpful than the message to which I replied.  I
guarantee that this style of argument will have absolutely no effect on my
opinion in a technical committee discussion.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Fri, 21 Aug 2009 18:45:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 18:45:16 GMT) Full text and rfc822 format available.

Message #145 received at 535645@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Thu, 20 Aug 2009 21:08:01 -0700
On Thu, 20 Aug 2009, Russ Allbery wrote:
> In the meantime, I think it's reasonable for ftpmaster to pick the
> poison that they want to live with between the two ugly solutions
> that have been put forward. If they think that ia32-libs is less
> broken in the short term than ia32-libs-tools, I don't want to argue
> with them, and I don't see a lot of compelling need to have both of
> them.

Given that at least three of the ctte members have indicated that
they're unwilling to override the ftpmasters,[1] should we go ahead
and call for a vote along these lines:

1. The CTTE declines to override ftpmaster's decision to remove
ia32-libs-tools.

2. Further Discussion

or is there additional information which would convince the CTTE to
override the ftpmasters which we feel wouldn't convince the ftpmasters
to allow its inclusion?


Don Armstrong

1: I've personally not heard anything that convinces me that
overriding them is optimal; I just haven't voiced an opinion on this
because I wanted to be sure I wasn't missing something.
-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

http://www.donarmstrong.com              http://rzlab.ucr.edu




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sat, 22 Aug 2009 04:06:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 22 Aug 2009 04:06:07 GMT) Full text and rfc822 format available.

Message #150 received at 535645@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Fri, 21 Aug 2009 22:34:06 -0500
On Thu, Aug 20 2009, Don Armstrong wrote:

> On Thu, 20 Aug 2009, Russ Allbery wrote:
>> In the meantime, I think it's reasonable for ftpmaster to pick the
>> poison that they want to live with between the two ugly solutions
>> that have been put forward. If they think that ia32-libs is less
>> broken in the short term than ia32-libs-tools, I don't want to argue
>> with them, and I don't see a lot of compelling need to have both of
>> them.
>
> Given that at least three of the ctte members have indicated that
> they're unwilling to override the ftpmasters,[1] should we go ahead
> and call for a vote along these lines:
>
> 1. The CTTE declines to override ftpmaster's decision to remove
> ia32-libs-tools.
>
> 2. Further Discussion
>
> or is there additional information which would convince the CTTE to
> override the ftpmasters which we feel wouldn't convince the ftpmasters
> to allow its inclusion?
>
> Don Armstrong

        At this point, I must confess that the  ia32-libs-tools
 inclusion argument does not have the techical underpinnings it needs to
 convince me that inclusion would be a net benefit to Debian.

        While I am not sure that the rejection of the package, and the
 subsequent communication about the underlying reasons from the
 viewpoint of the ftp-masters were done as well as they cold have been,
 I do not feel that rises to the level that would justify a delegate
 override.

        I would add a suggestion to the resolution that the CTTE invites
 the ftp-masters to share their reasons with the package maintainer, but
 otherwise the draft above looks OK.

        manoj
-- 
Life is like a bowl of soup with hairs floating on it.  You have to eat
it nevertheless. -- Flaubert
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#535645; Package tech-ctte. (Sun, 23 Aug 2009 02:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 02:36:03 GMT) Full text and rfc822 format available.

Message #155 received at 535645@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 535645@bugs.debian.org
Subject: Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Date: Sat, 22 Aug 2009 19:33:19 -0700
On Fri, 21 Aug 2009, Manoj Srivastava wrote:
>  I would add a suggestion to the resolution that the CTTE invites
>  the ftp-masters to share their reasons with the package maintainer,
>  but otherwise the draft above looks OK.

Ok. How about:

1. The CTTE declines to override ftpmaster's decision to remove
ia32-libs-tools. The CTTE suggests that ftpmaster make a clear
statement regarding the reasoning behind this rejection.

2. Further Discussion


Don Armstrong

-- 
If it jams, force it. If it breaks, it needed replacing anyway.
 -- Lowery's Law

http://www.donarmstrong.com              http://rzlab.ucr.edu




Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 27 Aug 2009 22:15:02 GMT) Full text and rfc822 format available.

Reply sent to Don Armstrong <don@debian.org>:
You have taken responsibility. (Fri, 04 Sep 2009 23:57:04 GMT) Full text and rfc822 format available.

Notification sent to Goswin Brederlow <goswin-v-b@web.de>:
Bug acknowledged by developer. (Fri, 04 Sep 2009 23:57:05 GMT) Full text and rfc822 format available.

Message #162 received at 535645-done@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 535645-done@bugs.debian.org
Subject: Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools
Date: Fri, 4 Sep 2009 16:47:14 -0700
On Wed, 02 Sep 2009, Don Armstrong wrote:
> I vote 1 2 3.

Since 6 people have voted 1 first, the outcome is no longer in doubt,
so:

  The Debian Technical Committee:

  1. declines to override the ftp team decision to remove the
  ia32-libs-tools package from the archive, finding insufficient technical
  justification to warrant an override, and

  2. reaffirms the ftp team's authority to exercise their own judgement in
  deciding to remove packages from the archive, whenever this is done for
  reasons consistent with the twin mandates to keep the archive operational
  and to support the archive needs of the Debian Project.

  The Committee further recommends:

  3. that the ftp team recognize that it's important for maintainers to feel
  empowered and in control of their packages, and therefore be willing to
  provide, upon a request from any Debian Developer, an accounting of the
  objective, measurable, technical conditions that a rejected package must
  meet in order to enter the archive, and

  4. that the petitioner and ia32-libs-tools package maintainer, Goswin von
  Brederlow, solicit the help of an upload sponsor to approach the ftp team
  in accordance with 3. above, so that any technical obstacles to this
  package's reintroduction to the archive may be laid out for consideration.


is the resolution of this bug.


Don Armstrong

-- 
J.W. Grant: "Bastard!"
Rico: "Yes, Sir. In my case, an accident of birth. But you, Sir,
you're a self-made man."
 -- Henry "Rico" Fardan in "The Professionals"

http://www.donarmstrong.com              http://rzlab.ucr.edu




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 03 Oct 2009 07:38:40 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 14:04:30 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.