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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Fri, Aug 21, 2009 at 11:07:31AM +0200, Goswin von Brederlow wrote:
>> > Concretely, as I have argued previously, there is a difference of scale
>> > between ia32-apt-get and other related tools.  dpkg-cross is ugly, but it 
>> > is
>> > low level and therefore has built-in barriers to adoption; it's not a tool
>> > that casual users are going to use to cross-install arbitrary libraries,
>> > it's a tool that embedded developers can use as a basis for their own
>> > private infrastructure to set up and maintain cross-build environments.
>
>> > It also, last I looked at it, was entirely free of the potential multiarch
>> > file conflicts discussed in this bug.  (I acknowledge that you have agreed
>> > to address these issues for ia32-apt-get, but at the time the package was
>> > removed it's my understanding that they had not been addressed.)
>
>> True. But I have never been asked to address them. Implementing
>> compatibility with multiarch requires multiarch to be implemented at
>> least party. You can not expect ia32-libs-tools to be compatible with
>> multiarch before it even was specified what it is.
>
> In http://lists.debian.org/debian-devel/2009/03/msg00638.html ff., I asked
> that biarch packages (which encompasses ia32-apt-get) not install anything
> into the multiarch library paths, to keep these paths clear for the
> multiarch implementation.  You asserted that there was no need to do this
> because multiarch packages would already need to conflict with corresponding
> biarch packages, a premise which I have never accepted.
>
> While not a statement that ia32-apt-get *would* use these paths, it seemed

And it never has used them.

> clear that you didn't consider it a problem if they (and related packages)
> *did* use these paths.

That was based on my premise that the biarch and multiarch package of
a library should never be installed at the same time. Binaries would
get the wrong library if versions differ and potentially not work. You
seem to disagree with that. If you take that premise away then
obviously using the same file location is a problem.

> The path structure of multiarch is one part that has been specified for
> years.  You can hardly claim to have been unaware of this.

The initial idea was to leave libraries in that path if packages
natively already use that path. Sorry that I forgot about your
previous objection but that is why it is good to discuss plans. I
agreed not to use the paths, i.e. move libraries out of there even if
the native package has them there. So I consider that problem
resolved.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Fri, Aug 21, 2009 at 11:07:31AM +0200, Goswin von Brederlow wrote:
> > Concretely, as I have argued previously, there is a difference of scale
> > between ia32-apt-get and other related tools.  dpkg-cross is ugly, but it is
> > low level and therefore has built-in barriers to adoption; it's not a tool
> > that casual users are going to use to cross-install arbitrary libraries,
> > it's a tool that embedded developers can use as a basis for their own
> > private infrastructure to set up and maintain cross-build environments.

> > It also, last I looked at it, was entirely free of the potential multiarch
> > file conflicts discussed in this bug.  (I acknowledge that you have agreed
> > to address these issues for ia32-apt-get, but at the time the package was
> > removed it's my understanding that they had not been addressed.)

> True. But I have never been asked to address them. Implementing
> compatibility with multiarch requires multiarch to be implemented at
> least party. You can not expect ia32-libs-tools to be compatible with
> multiarch before it even was specified what it is.

In http://lists.debian.org/debian-devel/2009/03/msg00638.html ff., I asked
that biarch packages (which encompasses ia32-apt-get) not install anything
into the multiarch library paths, to keep these paths clear for the
multiarch implementation.  You asserted that there was no need to do this
because multiarch packages would already need to conflict with corresponding
biarch packages, a premise which I have never accepted.

While not a statement that ia32-apt-get *would* use these paths, it seemed
clear that you didn't consider it a problem if they (and related packages)
*did* use these paths.

The path structure of multiarch is one part that has been specified for
years.  You can hardly claim to have been unaware of this.

> Ftp-master does not tell why they removed it. They only say they won't
> let it back.

> And now I am supposed to magically address the concerns nobody is
> willing to state?

I was assuming that the process would involve discussion between you and the
ftp team about the specific problems perceived with the package, possibly
using your sponsor as a proxy.  I don't know that you would find magic to be
a particularly successful strategy.

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


signature.asc
Description: Digital signature

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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Thu, Aug 20, 2009 at 02:31:35PM +0200, Goswin von Brederlow wrote:
>> > 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.]
>
>> 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.
>
> An unfounded conclusion.  The ftp team have not been subscribed to this bug
> or cc:ed on this mailing list thread.

Wrong. Andreas Barth specifically asked ftp-master for clarification
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645#58

There has been no responce to that request that I can see.

> If the primary object of this bug report is to get a clarification from the
> ftp masters, then this is quite irregular.  Since the constitution states
> that "Nothing in this constitution imposes an obligation on anyone to do
> work for the Project", we have no authority to compel the ftp masters to
> explain their removal decision in any more detail than they already have;
> constitutionally, the only authority the TC has is to override the removal
> decision.

Sorry, but that argument is just bullshit. By voluntary accepting the
job of ftp-master the persons have accepted a moral obligation to do a
good job, to be open and accountable.

As you say the TC has the authority to override the removal
decision. And the first step to deciding wether or not the decision
should be overridden must be finding out the reasons for the
decision. The TC might not have a constitutional authority to demand
an explaination but I sure would hope it would override any decision
for which ftp-master, or any delegate for that matter, is unwilling or
unable to give a reason for.  Having a small subset of Debian making
secret decisions for all of Debian goes against everything Debian
stands for.

You might not have the authority to demand an explaination but you do
have to power to make them give one or be overruled. What I'm asking
for is your willingness to weald that power.

> I've cc:ed the ftp team now and invite them to make clear their objections
> to reintroducing the ia32-apt-get package in the archive, since so far we
> have only inference and speculation to go by.  I do think it's important
> that when the ftp team makes decisions about package inclusion in the
> archive, that there be empirical, measurable reasons supporting those
> decisions; and that, at least upon request of a DD, the ftp team be willing
> to spell out the conditions for a package's acceptance into the archive
> (which may be a superset of the reasons for refusal).
>
> Note that I say DD, since non-DD maintainers aren't in a position to upload
> new packages directly to the archive anyway; the ftp team shouldn't feel
> compelled to justify package rejects / removals if no one with upload rights
> is contesting the decision.

That request has been made by Andreas Barth.

>> 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.
>
> False.  The ftp team did not remove the package from the archive at my
> direction, and even if they had, the authority to make that decision is
> theirs, not mine.  You don't get to game the tech committee's rules just
> because a member of the TC argues against your position.
>
> In this thread, I have merely elucidated the reasons why I don't believe the
> ftp-master decision should be overridden and why I would be unlikely to make
> a different decision in their place.

Ok, so we are still 100% in the dark why ia32-libs-tools was removed
from the archive. In my eyes that makes the removal arbitrary.

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

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

[Bdale Garbee]

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.

Bdale



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Thu, Aug 20, 2009 at 02:31:35PM +0200, Goswin von Brederlow wrote:
> > 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.]

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

An unfounded conclusion.  The ftp team have not been subscribed to this bug
or cc:ed on this mailing list thread.

If the primary object of this bug report is to get a clarification from the
ftp masters, then this is quite irregular.  Since the constitution states
that "Nothing in this constitution imposes an obligation on anyone to do
work for the Project", we have no authority to compel the ftp masters to
explain their removal decision in any more detail than they already have;
constitutionally, the only authority the TC has is to override the removal
decision.

I've cc:ed the ftp team now and invite them to make clear their objections
to reintroducing the ia32-apt-get package in the archive, since so far we
have only inference and speculation to go by.  I do think it's important
that when the ftp team makes decisions about package inclusion in the
archive, that there be empirical, measurable reasons supporting those
decisions; and that, at least upon request of a DD, the ftp team be willing
to spell out the conditions for a package's acceptance into the archive
(which may be a superset of the reasons for refusal).

Note that I say DD, since non-DD maintainers aren't in a position to upload
new packages directly to the archive anyway; the ftp team shouldn't feel
compelled to justify package rejects / removals if no one with upload rights
is contesting the decision.

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

False.  The ftp team did not remove the package from the archive at my
direction, and even if they had, the authority to make that decision is
theirs, not mine.  You don't get to game the tech committee's rules just
because a member of the TC argues against your position.

In this thread, I have merely elucidated the reasons why I don't believe the
ftp-master decision should be overridden and why I would be unlikely to make
a different decision in their place.

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

I don't think any of this is a justification for overriding the ftp team.
The ftp team is not obligated to treat any package as binding precedent when
considering the acceptance or removal of another.

Concretely, as I have argued previously, there is a difference of scale
between ia32-apt-get and other related tools.  dpkg-cross is ugly, but it is
low level and therefore has built-in barriers to adoption; it's not a tool
that casual users are going to use to cross-install arbitrary libraries,
it's a tool that embedded developers can use as a basis for their own
private infrastructure to set up and maintain cross-build environments.

It also, last I looked at it, was entirely free of the potential multiarch
file conflicts discussed in this bug.  (I acknowledge that you have agreed
to address these issues for ia32-apt-get, but at the time the package was
removed it's my understanding that they had not been addressed.)

> So in conclusion I would ask the CTTE to suspend the ftp-master
> removal and then mediate between Steve and me.

As I have not made any decision in this matter aside from my decision how to
vote on the question of overriding the ftp-masters, you don't have standing
to make this request.

> On the other hand I have, based on the multiarch proposal from Steve,
> detailed briefly [1] how ia32-apt-get will a

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

[Goswin von Brederlow]

Don Armstrong  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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 535645 moreinfo
Bug #535645 {Done: Debian Archive Maintenance 
} [tech-ctte] Wrongfull removal of 
ia32-libs-tools
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Don Armstrong]

X-Loop
ow...@bugs.debian.org: Resent-Date: Wed, 19 Aug 2009 02:36:01 +
Resent-Message-ID: 
Resent-Sender: ow...@bugs.debian.org
X-Debian-PR-Message: followup 535645
X-Debian-PR-Package: tech-ctte
X-Debian-PR-Keywords: 
Received: via spool by 535645-sub...@bugs.debian.org id=B535645.125064924130108
  (code B ref 535645); Wed, 19 Aug 2009 02:36:01 +
Received: (at 535645) by bugs.debian.org; 19 Aug 2009 02:34:01 +
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
(2007-08-08) on rietz.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0. Tokens: new, 24; hammy, 114; neutral, 60; spammy,
3. spammytokens:0.987-1--grievance, 0.973-+--satisfaction, 
0.939-+--research
hammytokens:0.000-+--H*r:nullmailer, 0.000-+--H*u:1.5.18,
0.000-+--H*UA:2008-05-17, 0.000-+--H*u:2008-05-17, 0.000-+--H*UA:1.5.18
X-Spam-Status: No, score=-9.5 required=4.0 tests=AWL,BAYES_00,FOURLA,
FROMDEVELOPER,HAS_BUG_NUMBER,VALID_BTS_CONTROL autolearn=ham
version=3.2.3-bugs.debian.org_2005_01_02
Received: from rzlab.ucr.edu ([138.23.92.77])
by rietz.debian.org with esmtp (Exim 4.63)
(envelope-from )
id 1Mdazx-0007of-7T; Wed, 19 Aug 2009 02:34:01 +
Received: from rzlab.ucr.edu (archimedes.ucr.edu [138.23.92.79])
by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n7J2Xx3j016890;
Tue, 18 Aug 2009 19:34:00 -0700
Received: (nullmailer pid 19093 invoked by uid 1000);
Wed, 19 Aug 2009 02:33:54 -
Date: Tue, 18 Aug 2009 19:33:54 -0700
From: Don Armstrong 
To: Goswin von Brederlow , 535...@bugs.debian.org
Message-ID: <20090819023354.gs9...@rzlab.ucr.edu>
Mail-Followup-To: Goswin von Brederlow ,
535...@bugs.debian.org
References: <87ocqpzrk8@frosties.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87ocqpzrk8@frosties.localdomain>
User-Agent: Mutt/1.5.18 (2008-05-17)

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



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Sun, Aug 09, 2009 at 11:18:27PM +0200, Goswin von Brederlow wrote:
>> > 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.
>
> $ zgrep usr/lib/i486-linux-gnu dists/unstable/Contents-amd64.gz |grep -c wine
> 921
> $
>
> These are biarch packages, using the i486 path on amd64.
>
> This is not multiarch at all.

No. That is the extra doubly ugly wine hack that uses the precompiled
i386 build tree in the source to generate the amd64 package. Don't
hold that against ia32-libs-tools.

Under ia32-apt-get the i386 wine package would be installed, not the
even uglier than ia32-libs wine hack. With ia32-apt-get that package
could actualy be removed from the archive making things cleaner.

>> If you think that is wrong then that is a bug in wine. Nothing to do
>> with ia32-libs-tools.
>
> If a package that ships files in the multiarch paths is installed using
> ia32-libs-tools, where will the resulting biarch package's files be located? 
> Will they not be in the multiarch paths?

They will be wherever you tell me to put them.

>> > -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.
>
> That has nothing to do with being -dev packages.
>
>> They need a multiarch capable extended toolchain, meaning libtool,
>> pkg-config,
>
> You have not demonstrated that this is dependent on the passing of a stable
> release cycle.  If you had any sense at all, you would be working out a
> design for what *does* need to happen here instead of wasting everyone's
> time with ia32-libs-tools.
>
>> automake, autoconf.
>
> Unlikely that anything needs to change here, but not relevant to -dev
> packages anyway.
>
>> They need to work with the existing biarch -dev packages or have to
>> replace them.
>
> Which, again, does not block on having an intervening release cycle.
>
>> Last I heart multiarchifying -dev packages was not planed for Stage 1
>> of the multiarch proposal. Has that changed?
>
> No.  Who said that stage 2 has to wait until after squeeze is out?

Ok, then I stand corrected.

My point was that all of multiarch will not be done by the end of
August and I think that still stands.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Sun, Aug 09, 2009 at 06:32:38PM -0600, Bdale Garbee wrote:
>> On Sun, 2009-08-09 at 16:37 -0700, Steve Langasek wrote:
>
>> > This assumes that users will continue to have ia32-libs-tools installed
>> > during the transition to multiarch.  What guarantees that this will be the
>> > case?  Does removing ia32-libs-tools also remove all the packages that were
>> > installed using it?
>
>> Interesting thought.  If all packages generated by ia32-libs-tools were
>> configured to depend on ia32-libs-tools, that might allow a much cleaner
>> conflict specification?  Just conflict with ia32-libs-tools?
>
> The conflict specification would be cleaner; the upgrade path would not, as
> conflicts at the base of a dependency tree tend to confuse apt into giving
> suboptimal upgrade solutions.

The prerm script could fail if ia32-* packages are left installed or I
could add a depends.

But if you want depends so you can conflict with a single package then
there is no need to depend on ia32-libs-tools. I already wrote,
multiple times, that the recent ia32-libs-tools generated packages all
"Provides: ia32-abi". So there is a single "package" to conflict
against. That was added for the benefit of ia32-libs and ia32-libs-gtk
to conflict with but works for anything.

I have absolutely no problem with multiarch conflicting ia32-abi if
Debian chooses that as upgrade path. Ia32-libs-tools should still be
in debian though, at least for a while longer, to give people the
chance to upgrade to where everything "Provides: ia32-abi".

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Sun, Aug 09, 2009 at 06:32:38PM -0600, Bdale Garbee wrote:
> On Sun, 2009-08-09 at 16:37 -0700, Steve Langasek wrote:

> > This assumes that users will continue to have ia32-libs-tools installed
> > during the transition to multiarch.  What guarantees that this will be the
> > case?  Does removing ia32-libs-tools also remove all the packages that were
> > installed using it?

> Interesting thought.  If all packages generated by ia32-libs-tools were
> configured to depend on ia32-libs-tools, that might allow a much cleaner
> conflict specification?  Just conflict with ia32-libs-tools?

The conflict specification would be cleaner; the upgrade path would not, as
conflicts at the base of a dependency tree tend to confuse apt into giving
suboptimal upgrade solutions.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bdale Garbee]

On Sun, 2009-08-09 at 16:37 -0700, Steve Langasek wrote:

> This assumes that users will continue to have ia32-libs-tools installed
> during the transition to multiarch.  What guarantees that this will be the
> case?  Does removing ia32-libs-tools also remove all the packages that were
> installed using it?

Interesting thought.  If all packages generated by ia32-libs-tools were
configured to depend on ia32-libs-tools, that might allow a much cleaner
conflict specification?  Just conflict with ia32-libs-tools?

Bdale



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

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

$ zgrep usr/lib/i486-linux-gnu dists/unstable/Contents-amd64.gz |grep -c wine
921
$

These are biarch packages, using the i486 path on amd64.

This is not multiarch at all.

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

If a package that ships files in the multiarch paths is installed using
ia32-libs-tools, where will the resulting biarch package's files be located? 
Will they not be in the multiarch paths?

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

That has nothing to do with being -dev packages.

> They need a multiarch capable extended toolchain, meaning libtool,
> pkg-config,

You have not demonstrated that this is dependent on the passing of a stable
release cycle.  If you had any sense at all, you would be working out a
design for what *does* need to happen here instead of wasting everyone's
time with ia32-libs-tools.

> automake, autoconf.

Unlikely that anything needs to change here, but not relevant to -dev
packages anyway.

> They need to work with the existing biarch -dev packages or have to
> replace them.

Which, again, does not block on having an intervening release cycle.

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

No.  Who said that stage 2 has to wait until after squeeze is out?

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Sun, Aug 09, 2009 at 10:59:24PM +0200, Goswin von Brederlow wrote:
> > Per ,
> > 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: . Which
> >   means ia32-libs or ia32-libs-gtk for the old system or ia32-
> >   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.

This assumes that users will continue to have ia32-libs-tools installed
during the transition to multiarch.  What guarantees that this will be the
case?  Does removing ia32-libs-tools also remove all the packages that were
installed using it?

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Steve Langasek  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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Steve Langasek  writes:

> On Sat, Aug 08, 2009 at 07:15:13PM -0700, Russ Allbery wrote:
>> Goswin von Brederlow  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 ,
> 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: . Which
>   means ia32-libs or ia32-libs-gtk for the old system or ia32-
>   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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Sat, Aug 08, 2009 at 07:15:13PM -0700, Russ Allbery wrote:
> Goswin von Brederlow  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 ,
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: . Which
  means ia32-libs or ia32-libs-gtk for the old system or ia32-
  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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Andreas Barth  writes:

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

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

[Andreas Barth]

* Goswin von Brederlow (goswin-...@web.de) [090809 17:43]:
> Andreas Barth  writes:
> > * Goswin von Brederlow (goswin-...@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-/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-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Andreas Barth]

Hi,

* Goswin von Brederlow (goswin-...@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 +] [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 +] [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

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

[Goswin von Brederlow]

Andreas Barth  writes:

> * Goswin von Brederlow (goswin-...@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-/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 tw

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

[Andreas Barth]

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



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Russ Allbery  writes:

> Goswin von Brederlow  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 (r...@debian.org)   

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-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Goswin von Brederlow  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

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 +] [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 n