Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Thu, Feb 24, 2011 at 01:55:57PM +0100, Raphael Hertzog wrote: > On Wed, 23 Feb 2011, Steve Langasek wrote: > > A virtual package is a good idea, though - in fact, it's such a good idea > > that I remember now we discussed this back at DebConf and I'd subsequently > > forgotten about it. Thanks for jogging my memory! :) Yes, whether or not > > we add support in a stable point release, I think that if we don't go the > > dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual > > package. > But you would put those Pre-Depends: multiarch-foo on the (core) libraries > that should not disappear, right? Yep, exactly. > It seems cleaner to put it there rather than on utilities. > I would also favor any solution that doesn't involve any shlibs bump in > libc. We've gone to great length to have symbols support in many > libraries, it would be a pity to lose the benefits due to multi-arch (even > if multi-arch is great too!). Right, I think there's a consensus to go this direction then, and only add dependencies on a multiarch metapackage for those libraries that install to the new paths. 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
Hi, On Wed, 23 Feb 2011, Steve Langasek wrote: > A virtual package is a good idea, though - in fact, it's such a good idea > that I remember now we discussed this back at DebConf and I'd subsequently > forgotten about it. Thanks for jogging my memory! :) Yes, whether or not > we add support in a stable point release, I think that if we don't go the > dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual > package. But you would put those Pre-Depends: multiarch-foo on the (core) libraries that should not disappear, right? It seems cleaner to put it there rather than on utilities. I would also favor any solution that doesn't involve any shlibs bump in libc. We've gone to great length to have symbols support in many libraries, it would be a pity to lose the benefits due to multi-arch (even if multi-arch is great too!). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110224125557.ga21...@rivendell.home.ouaza.com
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Thu, Feb 24, 2011 at 12:03:18AM +0100, Andreas Barth wrote: > * Steve Langasek (vor...@debian.org) [110223 22:53]: > > We can handle this one of two ways. We can either bump the minimal > > dependency of *all* packages against libc, by adjusting shlibs/symbols in > > the eglibc package; or we can make adding the dependency a part of the > > standard library multiarchification recipe. > Or third, we could add the new path to eglibc in a stable point > update and into unstable, and either > a) have a virtual package provided, and for the core utilities > pre-depend on that virtual package (so that user systems are never > broken by the upgrade), or > b) don't multiarch the core utilities for the next stable release. b) doesn't help. This is about libraries changing location and making sure that they're on the runtime linker's path; this will affect every core library on the system and there's no way to except the core /utilities/ from that. (If you want a multiarch X stack this cycle, you need a multiarch zlib. Guess what depends on zlib? :) A virtual package is a good idea, though - in fact, it's such a good idea that I remember now we discussed this back at DebConf and I'd subsequently forgotten about it. Thanks for jogging my memory! :) Yes, whether or not we add support in a stable point release, I think that if we don't go the dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual package. -- 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: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 10:55:51PM +, Simon McVittie wrote:
> On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
> > we almost certainly will not be using the path which has been enabled
> > in glibc up to now, namely /lib/i486-linux-gnu.
> I'd heard that, and was somewhat concerned about whether that'd block
> multiarch for yet another release cycle; I'm glad to hear it isn't.
> One possibility that occurred to me is adding a Pre-Depends on a new package
> ("multiarch-enabler", perhaps) which is arch:any and just contains this
> file:
> # /etc/ld.so.conf.d/x86-linux-glibc.conf
> /lib/x86-linux-glibc
> /usr/lib/x86-linux-glibc
> Am I right in thinking that (probably only needed for the native architecture,
> even) would be enough to "bootstrap" support for the multiarch paths in the
> native architecture's linker far enough to perform the upgrade? A future
> libc6 could even Replace it or something.
> (It'd be a bit subtle by being transitively Essential, though.)
Currently I don't see any advantage of doing it this way, rather than having
libc provide this file directly and have affected package pre-depend on
libc. The only reason we might consider a separate binary package closer to
release is if we wind up with circular dependencies that break upgrades from
squeeze; so this is a good idea to keep in our back pocket as a fallback
plan, but until it's shown to be needed I think it's unnecessary complexity
that we should avoid.
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
> we almost certainly will not be using the path which has been enabled
> in glibc up to now, namely /lib/i486-linux-gnu.
I'd heard that, and was somewhat concerned about whether that'd block
multiarch for yet another release cycle; I'm glad to hear it isn't.
One possibility that occurred to me is adding a Pre-Depends on a new package
("multiarch-enabler", perhaps) which is arch:any and just contains this
file:
# /etc/ld.so.conf.d/x86-linux-glibc.conf
/lib/x86-linux-glibc
/usr/lib/x86-linux-glibc
Am I right in thinking that (probably only needed for the native architecture,
even) would be enough to "bootstrap" support for the multiarch paths in the
native architecture's linker far enough to perform the upgrade? A future
libc6 could even Replace it or something.
(It'd be a bit subtle by being transitively Essential, though.)
S
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110223225551.ga17...@reptile.pseudorandom.co.uk
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 23:29]: > Ah, I don't know the details; I take this as gospel from the GCC maintainers > that There Are Differences. Perhaps the differences are only optimization > rather than compatibility; but regardless, given that most distros use > i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu > is an odd bird to propose to standardize on. AFAIUI, we need the atomic locking the i386 and some early i486 don't have, we need an co-processor that not all i486 have (but that's an kernel issue - the math emulation code is instant root exploitable, and therefor not part of the kernel code), and that's it. However, we optimize for i586 IIRC. > > [1] As you said pre-depends are messy but the safe bet. It would be best if > > we could somehow ensure that libc6 is upgraded first and that everything > > needed for the unpack is still there at that point (i.e. some liberal > > use of pre-depends somewhere in just the base set instead of > > everywhere). > > Ok. I think that's certainly going to be more manageable than trying to add > pre-depends to everything, anyway. Any concerns about bumping the > dependency for all libraries via dpkg-shlibdeps? Yes, I don't like libary bumps, because that's annoying if we need backports of all packages just to make dpkg happy (and the other package would still work, but just dpkg would complain). But well, maybe still the best. Andi -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223230957.gz15...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 02:29:26PM -0800, Steve Langasek wrote: > > [1] As you said pre-depends are messy but the safe bet. It would be best if > > we could somehow ensure that libc6 is upgraded first and that everything > > needed for the unpack is still there at that point (i.e. some liberal > > use of pre-depends somewhere in just the base set instead of > > everywhere). > Ok. I think that's certainly going to be more manageable than trying to add > pre-depends to everything, anyway. Any concerns about bumping the > dependency for all libraries via dpkg-shlibdeps? What's the timeframe for eglibc to be ready? If it's able to migrate to testing fairly soon and as it's just shlibdeps and as it's at the beginning of the cycle, I don't really see any. It should not be the primary blocker for migration for weeks, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 22:53]: > We can handle this one of two ways. We can either bump the minimal > dependency of *all* packages against libc, by adjusting shlibs/symbols in > the eglibc package; or we can make adding the dependency a part of the > standard library multiarchification recipe. Or third, we could add the new path to eglibc in a stable point update and into unstable, and either a) have a virtual package provided, and for the core utilities pre-depend on that virtual package (so that user systems are never broken by the upgrade), or b) don't multiarch the core utilities for the next stable release. Andi -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223230318.gy15...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 11:15:02PM +0100, Philipp Kern wrote: > On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: > > [1] i486 is an arbitrary name that happens to correspond to the base > > instruction set that was in use on Debian at the time multiarch was first > > formulated, but it doesn't match the current base instruction set on Debian > > (i586) or Ubuntu (i686), doesn't match the directory configured in the > > current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look > > weird to other distributions when we try to talk to them about this since > > they've also long since moved to i686 as their base compatibility. > Sorry to skip multiarch[1], but I need to comment on this one. Isn't the > base instruction set still i486? I still haven't found any practical > example of a change of ISA between i486 and i586. For all means they seem > to be equivalent, with i686 being the next break. The only exception that > might be is that 486 can actually lack FPUs, while Pentiums don't. But > for all practically relevant cases I'd assume that they don't, and I'd be > surprised if we'd cater for that. Ah, I don't know the details; I take this as gospel from the GCC maintainers that There Are Differences. Perhaps the differences are only optimization rather than compatibility; but regardless, given that most distros use i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu is an odd bird to propose to standardize on. > Out of curiosity: Where will optimized libraries be placed? Multiarch can be combined transparently with hwcaps; so you can have /lib/i386-linux-gnu/i686/cmov/, /lib/alpha-linux-gnu/ev67/, etc. Multiarch also does not require that the libraries installed to the base directory are backwards-compatible with anything that you don't care about, so it's fine to have i686 libraries directly in /lib/i386-linux-gnu on a distro whose baseline is i686, while they're in a hwcap directory for another distro. > [1] As you said pre-depends are messy but the safe bet. It would be best if > we could somehow ensure that libc6 is upgraded first and that everything > needed for the unpack is still there at that point (i.e. some liberal > use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? -- 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: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: > [1] i486 is an arbitrary name that happens to correspond to the base > instruction set that was in use on Debian at the time multiarch was first > formulated, but it doesn't match the current base instruction set on Debian > (i586) or Ubuntu (i686), doesn't match the directory configured in the > current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look > weird to other distributions when we try to talk to them about this since > they've also long since moved to i686 as their base compatibility. Sorry to skip multiarch[1], but I need to comment on this one. Isn't the base instruction set still i486? I still haven't found any practical example of a change of ISA between i486 and i586. For all means they seem to be equivalent, with i686 being the next break. The only exception that might be is that 486 can actually lack FPUs, while Pentiums don't. But for all practically relevant cases I'd assume that they don't, and I'd be surprised if we'd cater for that. Out of curiosity: Where will optimized libraries be placed? Kind regards Philipp Kern [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). signature.asc Description: Digital signature
RFC: use of shlib bump for libc dependency on new multiarch directories?
Dear release team, Although the paths in which libraries will ultimately be installed for multiarch is not yet entirely settled, one thing that is clear is that on i386, we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu.[1] We will most likely be using either /lib/i386-linux-gnu or /lib/x86-linux-glibc instead, depending on the outcome of various ongoing discussions; and libraries installing to either one of these paths are going to need to make sure the new libc is installed first, or they'll instantly become unavailable on upgrade. We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. The first approach means that every library on the system will depend on the new libc as soon as it's rebuilt, whether or not it's installed to the multiarch library path. However, my handwavy estimate is that by the time wheezy is out we should have better than 80% library coverage with multiarch, so maybe that's not an issue at all. But it also may not be sufficient to ensure smooth upgrades either; dependencies don't guarantee unpack order, so what happens if a library needed by apt+dpkg to finish the unpack of the new libc gets disappeared out of the system path before libc itself gets unpacked? do we need to special-case the addition of pre-depends to any libraries that are needed by the package manager? Do we want pre-depends for *all* libraries, just in case? The second approach is going to be more error prone; it's one more step that has to be added to the process for converting a library package to multiarch, which means it's one more step that maintainers can forget and one of the easiest to go unnoticed for long periods in unstable/testing. We could mitigate this somewhat by having debhelper do something here by default when it sees multiarch paths in use, but that won't give us 100% archive coverage either (and oh, how the work I've been doing on my multiarch proof-of-concept bootstrap makes me wish it would :-). It also isn't viable anywhere we decide we need Pre-Depends, since most packages simply won't have a substitution in place for Pre-Depends that debhelper can hook into. Since this is an issue with high potential impact on squeeze->wheezy upgrades, Aurélien suggested that we solicit input from the release team here. Do you guys have any recommendations on how we should handle this, or any other concerns that I may have overlooked? 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. signature.asc Description: Digital signature
