Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools

[Goswin von Brederlow-2]

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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Goswin von Brederlow <goswin-v-b@...> 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@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Russ Allbery <rra@...> writes:

> Goswin von Brederlow <goswin-v-b@...> 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@...)               <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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Goswin von Brederlow (goswin-v-b@...) [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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Andreas Barth <aba@...> writes:

> * Goswin von Brederlow (goswin-v-b@...) [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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Goswin von Brederlow (goswin-v-b@...) [090809 17:43]:

> Andreas Barth <aba@...> writes:
> > * Goswin von Brederlow (goswin-v-b@...) [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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

Hi,

* Goswin von Brederlow (goswin-v-b@...) [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@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Andreas Barth <aba@...> writes:

> * Goswin von Brederlow (goswin-v-b@...) [090809 17:43]:
>> Andreas Barth <aba@...> writes:
>> > * Goswin von Brederlow (goswin-v-b@...) [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




--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Sat, Aug 08, 2009 at 07:15:13PM -0700, Russ Allbery wrote:
> Goswin von Brederlow <goswin-v-b@...> 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?

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.

I would vote against any resolution to override the ftp masters' decision to
remove this package from the archive.

--
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@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Steve Langasek <vorlon@...> 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@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Sun, Aug 09, 2009 at 11:46:38AM -0700, Russ Allbery wrote:

> 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?

Essentially correct, yes.  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.

--
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@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Sun, Aug 09, 2009 at 05:43:37PM +0200, Goswin von Brederlow wrote:
> 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.

ia32-libs and ia32-libs-gtk are broadly considered to be kludges.  These are
largely tolerable because their scope is self-limiting: the more libraries
that are added the harder it becomes to maintain the packages, so there's
pressure to only include those libraries for which there's the most critical
user demand.

ia32-libs-tools, OTOH, takes this kludged architecture and enshrines it in
an easy-to-use form that guarantees that biarch will expand without bounds,
effectively polluting the multiarch transition for *all* library packages.

> - 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.

Oh great, so experimental wine is now also using paths intended for
multiarch in biarch packages.

This is an FHS violation, and should be treated as a serious bug.

> 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).

-dev packages don't require a stable release cycle before conversion to
multiarch.

--
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@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Steve Langasek (vorlon@...) [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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Andreas Barth <aba@...> writes:

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

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?

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


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Russ Allbery (rra@...) [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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert]

> 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.

And careful there, rewriting debian/control in an automated way during
build time is a no go. So even if its done that way, it would mean
manual action.

--
bye, Joerg
Some NM:
"Essential: Yes" -- useful for a message when you do apt-get remove bash:


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Andreas Barth <aba@...> writes:

> * Steve Langasek (vorlon@...) [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

Maintainers are burdened with having to Conflicts/Replaces with:

  Package                         Popcon count
  ia32-libs                       7273
  ia32-libs-dev                      1
  ia32-libs-gtk                   4047
  ia32-libs-kde                   ??? ubuntu
  ia32-libs-scim                  ??? ubuntu
  ia32-libs-xulurunner            1408
  ia32-libs-libnspr4              1263
  ia32-libs-libnss3               1257
  ia32-libs-libssh2               1238
  ia32-libs-libidn11              1231
  ia32-libs-libcurl3              1221
  lib32*


On the other hand, assuming that an ia32-apt-get user will keep using
ia32-apt-get, the ia32-libs-tools generated packages will take care of
themself:

1) The generated packages can trivially conflict with the multiarch
packages as soon as dpkg understands the syntax.

2) If ia32-apt-get is used then it sits between the Packages.gz file
being downloaded and it being parsed by apt. It could esily add
Conflicts/Replaces entries in the multiarch packages on the fly the
same way it transforms Packages.gz now. Users would just have to use
ia32-apt-get long enough to replace all ia32-* packages with their
multiarch equivalent.

3) As mentioned in another mail my plan is to mirror package names
multiarch will use them when dpkg/apt support them. The converted
packages, always being a lower version than the input package, are
then natural predecesors of the multiarch packages and apt will just
update it like it updates foo 1.2-3 to foo 1.2-4 now. In effect
ia32-libs-tools will generate multiarch packages on the fly.

4) In recent versions all converted packages have "Provides:
ia32-abi". If need be (all the above are unsatisfactory) the mutliarch
dpkg can conflict with that causing them all to be removed in a single
stroke. Users can then reinstall the multiarch ones without problems.
The ia32-libs* packages can also Conflicts/Replaces: ia32-abi to allow
users to switch between the two methods at will.


I don't believe asking ia32-apt-get users, which are officially all
unstable users, to run "ia32-apt-get update; ia32-apt-get install
ia32-apt-get; ia32-apt-get update; ia32-apt-get dist-upgrade" (or
their frontend of choice) before switching on multiarch in apt/dpkg is
a burden. For most people that will happen naturally anyway.

There is also the issue that it has been around for 1 1/2 years and is
in use by a sizeable group of users already. There is no going back,
only forward.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Steve Langasek <vorlon@...> writes:

> On Sat, Aug 08, 2009 at 07:15:13PM -0700, Russ Allbery wrote:
>> Goswin von Brederlow <goswin-v-b@...> 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?
>
> 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.
>
> I would vote against any resolution to override the ftp masters' decision to
> remove this package from the archive.

This has also been addressed in ia32-libs-tools since then, or rather
I didn't see the trivial way to do it back then. The ia32-apt-get
mechanism transforms the binary-i386/Packages.gz file between apt
downloading and apt parsing it. Currently it transforms libfoo to
ia32-libfoo in that process. With multiarch packages it would see
libfoo as being multiarchified and just add "Conflicts: ia32-libfoo"
and "Replaces: ia32-libfoo" to its stanza.

So I believe that to be a non-issue.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Steve Langasek <vorlon@...> writes:

> On Sun, Aug 09, 2009 at 05:43:37PM +0200, Goswin von Brederlow wrote:
>> - 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.
>
> Oh great, so experimental wine is now also using paths intended for
> multiarch in biarch packages.
>
> This is an FHS violation, and should be treated as a serious bug.

No, it is using multiarch paths in native packages. The way packages
are supposed to do for multiarch. Maybe it is a bit ahead of the curve
but it is exactly doing what multiarch expects it to do.

If you think that is wrong then that is a bug in wine. Nothing to do
with ia32-libs-tools.

>> 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).
>
> -dev packages don't require a stable release cycle before conversion to
> multiarch.

They do if they need an architecture specific depenency, think perl,
python, ocaml, apache. They need a multiarch capable extended
toolchain, meaning libtool, pkg-config, automake, autoconf. They need
to work with the existing biarch -dev packages or have to replace
them.

Last I heart multiarchifying -dev packages was not planed for Stage 1
of the multiarch proposal. Has that changed?

Maybe you misunderstood me. I don't mean libfoo-dev_1.2-3_amd64.deb on
amd64. That probably/hopefully works smoothly with Stage 1. I ment
libfoo-dev_1.2-3_i386.deb. Use case would be for example to compile
the latest wine on amd64 without having to need a full i386 build
chroot.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Andreas Barth <aba@...> writes:

> * Russ Allbery (rra@...) [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.

As said in another mail that isn't even needed at all within the
framework of ia32-libs-tools.

> 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).

Seems to be a big misunderstanding here. Ia32-libs-tools is not using
/usr/lib/$(DEB_HOST_GNU_TYPE) and it is not going to just randomly
start using /usr/lib/$(DEB_HOST_GNU_TYPE).

I was talking about packages in Debian starting to use it as per the
multiarch proposal:

https://wiki.ubuntu.com/MultiarchSpec#Filesystem layout

I believe wine is the first package that is experimenting with using
that.

> 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.

I want to be clear here. The plan I gave is the transition plan from
ia32-apt-get to multiarch. In

  http://lists.debian.org/debian-devel/2009/07/msg00120.html

Pierre Habouzit acused me of "has no forward upgrate path to a
multiarch work". Well, there is my planed path. The plan I presented
was to show that ia32-apt-get will not stand in the way or hinder
multiarch or place extra work on maintainers. It will, if all goes
according to plan, transition to multiarch with the push of a button.

I do not have a plan how Debian (esspecially with ia32-libs and
ia32-libs-gtk) will transition to multiarch. But when they do then
ia32-apt-get will follow.

> A few more (not so) random mails in that context:
> http://lists.debian.org/debian-devel/2009/07/msg00093.html

Yannick was happy about ia32-apt-get because it let him do thinks he
could not do before. Pierre was enraged about it. I think he was still
writing about the fatefull version 18 upload that cause all the
ruccus, the one where ia32-libs pulled in ia32-apt-get for the first
time instead of users having to specifically install it themself. That
was reverted the night before that mail so it realy is purely a users
choice to install ia32-apt-get.

As in any flame war emotions ran high. Please keep that in mind when
reading that flame war.

> http://lists.debian.org/debian-devel/2009/07/msg00060.html -
>   ftp-masters on removal

Also about the dpkg/apt diversion and taking over ia32-libs. Or so I
assumed. That mail was following the discussion on irc where Mark
Hymers offered to maintain ia32-libs and I imediatly agreed and ask
Joerg to remove the offending ia32-libs/ia32-libs-gtk packages,
prepared the version 22 upload and filed the initial ROM bug. I
assumed, maybe wrongly, that that mail was just reflecting the current
status as discussed on irc so people would stop bugging ftp-master
about it.

I did not get any indication on irc or understood that mail in a way
that Joerg ment removing all of ia32-libs-tools completly. And at the
end of the mail he says: "It has mainly been written due to the fact
that we have been asked by multiple people to remove ia32-libs-tools
but don't want to do so until a consensus has been reached on what
we're going to do to replace it." Shoudn't the packages maintainer be
involved in finding a consensus?

> http://lists.debian.org/debian-devel/2009/07/msg00120.html

As said above my plan solves the transition to multiarch and only
multiarch can solve the other point about converting packages being a
hack.

> 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.

I think after 1 1/2 years it is a bit late for just removing the
package. People have been using it for a long time and it has grown a
user base. If there really is a reason why ia32-libs-tools would make
the transition way harder then that obviously has to be fixed, not
ignored. I think my transition plan solves this issue and will go
nicely with debian adopting multiarch.

Removing ia32-libs-tools just leaves all the users of it high and dry
and will make transitioning to multiarch difficult for them. That is
certain.

Keeping ia32-libs-tools means I can work along side the multiarch
developement and make the transition as smooth as possible. And as you
said it is still unanswered if there is a problem at all.

So one has to weigh certain problems against possible problems that
can be fixed as they become clear.

You know what I would prefer.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...