FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-02-2011, 07:36 AM
Steve Langasek
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

Hi folks,

One of the things that held up the deployment of multiarch-friendly library
packages in Debian was the recognition that the host triplet used on i386,
i486-linux-gnu, was not suitable for cross-distro standardization because it
encodes information about the current default optimization that we've chosen
for our toolchain.

After much soul-searching, a solution has been agreed upon that will let us
use i386-linux-gnu as the multiarch path component on i386. This solution
should be codified shortly in Debian policy via bug #619186, and it has been
signed off on by the dpkg, eglibc, and gcc maintainers.

Now the trouble is that, owing to a case of poor timing, neither the gcc nor
the eglibc in squeeze supports looking in /lib/i386-linux-gnu - they only
support looking in /lib/i486-linux-gnu. So any library that is unpacked to
/lib/i386-linux-gnu becomes invisible to ld.so unless a newer ld.so is
unpacked first. And since Depends only guarantees configuration order, not
unpack order, that means Pre-Depends... for every library that is migrated
for multiarch.

Specifically, the plan is that any package in wheezy shipping a runtime
library in a multiarch directory should declare a Pre-Depends on the
metapackage 'multiarch-support'. This package will be built from eglibc
source, and for each architecture it will depend on the appropriate version
of libc that implements support for the corresponding multiarch lib
directory.[1]

I'm reasonably confident that we have this right, having discussed this with
the release team and tested it under "live fire" in Ubuntu; but as Jonathan
Nieder rightly points out in the policy bug, policy asks for Pre-Depends to
be discussed on debian-devel, not just on debian-release.

Does anyone see a better way to achieve this result, that I've overlooked?
Will adding this pre-depends on multiarch-support cause any problems that we
haven't yet identified?

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

[1] For those who care, this is not being done with a virtual package
because that creates an unsolvable pre-depends loop between libc6 and
libgcc1 of the *foreign* architecture the first time you try to install
multiarch; making this a real package lets us break the loop for the foreign
architecture. It also has the side effect that multiarch-support can have
an appropriate versioned dependency on libc for each architecture, so that
on !i386, it's installable against the squeeze libc in a partial upgrade.
 
Old 04-05-2011, 02:31 AM
Steve Langasek
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
> Specifically, the plan is that any package in wheezy shipping a runtime
> library in a multiarch directory should declare a Pre-Depends on the
> metapackage 'multiarch-support'. This package will be built from eglibc
> source, and for each architecture it will depend on the appropriate version
> of libc that implements support for the corresponding multiarch lib
> directory.[1]

> I'm reasonably confident that we have this right, having discussed this with
> the release team and tested it under "live fire" in Ubuntu; but as Jonathan
> Nieder rightly points out in the policy bug, policy asks for Pre-Depends to
> be discussed on debian-devel, not just on debian-release.

> Does anyone see a better way to achieve this result, that I've overlooked?
> Will adding this pre-depends on multiarch-support cause any problems that we
> haven't yet identified?

So we have a consensus of one here on the list? I should make a point of
always bringing up policy proposals in parallel to ongoing threads about
network manager, apparently it's the easiest way to meet the requirement for
posting to debian-devel without having to actually discuss anything

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 04-05-2011, 02:48 AM
Russ Allbery
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

Steve Langasek <vorlon@debian.org> writes:

> One of the things that held up the deployment of multiarch-friendly
> library packages in Debian was the recognition that the host triplet
> used on i386, i486-linux-gnu, was not suitable for cross-distro
> standardization because it encodes information about the current default
> optimization that we've chosen for our toolchain.

> After much soul-searching, a solution has been agreed upon that will let
> us use i386-linux-gnu as the multiarch path component on i386. This
> solution should be codified shortly in Debian policy via bug #619186,
> and it has been signed off on by the dpkg, eglibc, and gcc maintainers.

> Now the trouble is that, owing to a case of poor timing, neither the gcc
> nor the eglibc in squeeze supports looking in /lib/i386-linux-gnu - they
> only support looking in /lib/i486-linux-gnu. So any library that is
> unpacked to /lib/i386-linux-gnu becomes invisible to ld.so unless a
> newer ld.so is unpacked first. And since Depends only guarantees
> configuration order, not unpack order, that means Pre-Depends... for
> every library that is migrated for multiarch.

This sounds very similar to how the X.org transition was handled for all
binaries that were using the old, now-retired directories, and I don't
recall Pre-Depends in particular causing anything to explode there. Also,
Pre-Depends on glibc is less risky than Pre-Depends on a lot of other
things, since glibc is generally already configured very close to the
start of any apt or aptitude run.

So, in short, it seems fine to me.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87iput76qz.fsf@windlord.stanford.edu">http://lists.debian.org/87iput76qz.fsf@windlord.stanford.edu
 
Old 04-05-2011, 05:49 AM
Jan Hauke Rahm
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Mon, Apr 04, 2011 at 07:31:49PM -0700, Steve Langasek wrote:
> On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
> > Specifically, the plan is that any package in wheezy shipping a runtime
> > library in a multiarch directory should declare a Pre-Depends on the
> > metapackage 'multiarch-support'. This package will be built from eglibc
> > source, and for each architecture it will depend on the appropriate version
> > of libc that implements support for the corresponding multiarch lib
> > directory.[1]
>
> > I'm reasonably confident that we have this right, having discussed this with
> > the release team and tested it under "live fire" in Ubuntu; but as Jonathan
> > Nieder rightly points out in the policy bug, policy asks for Pre-Depends to
> > be discussed on debian-devel, not just on debian-release.
>
> > Does anyone see a better way to achieve this result, that I've overlooked?
> > Will adding this pre-depends on multiarch-support cause any problems that we
> > haven't yet identified?
>
> So we have a consensus of one here on the list? I should make a point of
> always bringing up policy proposals in parallel to ongoing threads about
> network manager, apparently it's the easiest way to meet the requirement for
> posting to debian-devel without having to actually discuss anything

Well, what did you expect? This is a rather complicated thing to assess,
and you've discussed it already with those who are well versed regarding
such issues. In fact, when I first read your intentention to add a
Pre-Depends on a large amount of packages, I figured that quite a lot
can break. We all know how Pre-Depends makes it harder for apt* and dpkg
to find a sensible order. But, since I cannot try it here *and* you
already included the maintainers of dpkg, eglibc, etc. and the release
team, who am I to object to their assessment? IOW, I guess you can read
the lack of responses as silent nodding...

(And now it's even easier to start a flame war about the knowledge of
aforementioned well versed developers. :-P)

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 04-05-2011, 09:12 AM
Adam Borowski
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
> Specifically, the plan is that any package in wheezy shipping a runtime
> library in a multiarch directory should declare a Pre-Depends on the
> metapackage 'multiarch-support'.

And the dependency would be added by either dpkg-dev, debhelper, or
dpkg-shlibdeps rather than being added to every single library by hand,
right?

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405091254.GA2958@angband.pl">http://lists.debian.org/20110405091254.GA2958@angband.pl
 
Old 04-05-2011, 10:12 AM
Simon McVittie
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Tue, 05 Apr 2011 at 11:12:54 +0200, Adam Borowski wrote:
> On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
> > Specifically, the plan is that any package in wheezy shipping a runtime
> > library in a multiarch directory should declare a Pre-Depends on the
> > metapackage 'multiarch-support'.
>
> And the dependency would be added by either dpkg-dev, debhelper, or
> dpkg-shlibdeps rather than being added to every single library by hand,
> right?

Because debhelper doesn't add any Pre-Depends yet, there's nowhere to put
the new dependency that would automatically be picked up. I believe the
current plan is that:

* debhelper adds multiarch-support to a new
${misc:Pre-Depends} substvar (which must be added to the library by hand)

* this is only relevant to packages that divert files into multiarch
directories, which would only happen with package-specific changes anyway
(bumping the debhelper compat level to 9, if nothing else)

* lintian should warn (error?) if a binary package has libraries in a multiarch
directory and doesn't pre-depend on multiarch-support

* lintian should perhaps also warn if a package uses debhelper compat 9
and doesn't pre-depend on ${misc:Pre-Depends}

Regards,
S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405101229.GA19892@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110405101229.GA19892@reptile.pseudorandom.co.uk
 
Old 04-05-2011, 10:25 AM
Neil Williams
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Tue, 5 Apr 2011 11:12:29 +0100
Simon McVittie <smcv@debian.org> wrote:

> * lintian should warn (error?) if a binary package has libraries in a multiarch
> directory and doesn't pre-depend on multiarch-support
>
> * lintian should perhaps also warn if a package uses debhelper compat 9
> and doesn't pre-depend on ${misc:Pre-Depends}

Instead:

Lintian error (and an ftpmaster REJECT) if debhelper compat 9 is set
with no ${misc:PreDepends} set because that prevents the
multiarch-support addition. A failure to convert ${misc:PreDepends} to
multiarch-support would be a debhelper bug and seems quite unlikely -
but worth checking at ftpmaster level, possibly.

Lintian error (and an ftpmaster REJECT) if a binary package (not just
a library) has multiarch paths without debhelper compat 9. (This
protects against uploading packages converted with tools like
dpkg-cross -M -A (>= 2.6.3).)

That way, if multiarch-support is no longer needed as a Pre-Depends, the
lintian error is still correct (but can be downgraded with only a
change in lintian) and the rest of the archive packages need no further
changes. The next package rebuild after we decide that
multiarch-support becomes a no-op and ${misc:PreDepends} goes back to
being the empty string automatically, via a change in debhelper.

That leaves everything in the hands of the debhelper tool to add or
not add the actual Pre-Depends and in the hands of lintian to
check correct deployment, without needing any further package changes
across the archive.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-05-2011, 10:47 AM
Ben Hutchings
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Tue, 2011-04-05 at 11:25 +0100, Neil Williams wrote:
[...]
> Lintian error (and an ftpmaster REJECT) if a binary package (not just
> a library) has multiarch paths without debhelper compat 9. (This
> protects against uploading packages converted with tools like
> dpkg-cross -M -A (>= 2.6.3).)
[...]

Do you mean, 'with debhelper, but without debhelper compat 9'?
debhelper is of course not mandatory.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-05-2011, 10:56 AM
Neil Williams
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

On Tue, 05 Apr 2011 11:47:01 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:

> On Tue, 2011-04-05 at 11:25 +0100, Neil Williams wrote:
> [...]
> > Lintian error (and an ftpmaster REJECT) if a binary package (not just
> > a library) has multiarch paths without debhelper compat 9. (This
> > protects against uploading packages converted with tools like
> > dpkg-cross -M -A (>= 2.6.3).)
> [...]
>
> Do you mean, 'with debhelper, but without debhelper compat 9'?
> debhelper is of course not mandatory.

Yes.

Lintian error (and an ftpmaster REJECT) if a binary package (not just
a library) has multiarch paths without either debhelper compat 9 or the
multiarch-support Pre-Depends. (This protects against uploading
packages converted with tools like dpkg-cross -M -A (>= 2.6.3).)

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-05-2011, 05:51 PM
Russ Allbery
 
Default Proposed pre-depends addition: all multiarched libs -> multiarch-support

Simon McVittie <smcv@debian.org> writes:

> * lintian should warn (error?) if a binary package has libraries in a
> multiarch directory and doesn't pre-depend on multiarch-support

Yes, this is what we did for the X.org transition and it seemed to work
reasonably well.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4f8zivs.fsf@windlord.stanford.edu">http://lists.debian.org/87k4f8zivs.fsf@windlord.stanford.edu
 

Thread Tools




All times are GMT. The time now is 02:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org