Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-25 Thread Frank Lichtenheld
On Sat, Feb 25, 2006 at 07:55:00AM +0100, Christian Perrier wrote:
> OK, sorry for the confusion but I really didn't want to see Aurélien
> just stop this work which I'm pretty sure he's doing well.
> 
> For dpkg, I think I've seen some discussion but Guillem Jover and/or
> Frank Lichtenheld have probably a better picture. Anyway, the dpkg
> development model is now pretty much opened so anyone with
> ideas/skills/patches can probably come up and discuss in debian-dpkg...

The first part is not quite true yet; currently I have no real idea
of the needed/proposed changes to dpkg for multiarch. The second part
however is true: I will happily work with anyone who proposes multi-arch
patches for dpkg to test, discuss and integrate them...

(General remark without reference to any special incident: please use
the BTS for patches, do not post them directly to the list)

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-24 Thread Christian Perrier
(restricting the CC list to real lists)

Quoting Steve Langasek ([EMAIL PROTECTED]):
> On Fri, Feb 24, 2006 at 07:45:16AM +0100, Christian Perrier wrote:
> 
> > > After a discussion on IRC, it seems there is no consensus about how 
> > > multiarch should be done. Therefore I stop working on that (patches are 
> > > still welcome for glibc).
> 
> > Is this really the best thing to do?
> 
> > Even though there is no consensus (I overread the thread and anyway
> > most parts of it fly in the stratosphere from my point of view), I'm
> > not sure that abandoning the work is really the answer in this
> > situation.
> 
> I didn't interpret this as "abandoning" the work.  I think this is the right
> point to stop at on glibc right now -- we really need to have support for
> multiarch in dpkg an apt before usefully proceeding further.


OK, sorry for the confusion but I really didn't want to see Aurélien
just stop this work which I'm pretty sure he's doing well.

For dpkg, I think I've seen some discussion but Guillem Jover and/or
Frank Lichtenheld have probably a better picture. Anyway, the dpkg
development model is now pretty much opened so anyone with
ideas/skills/patches can probably come up and discuss in debian-dpkg...

For apt, ahem.Michael is pretty much alone doing visible
development work. Some help here would probably be welcomedat
least from my very far point of view. Please show up on the devel list
([EMAIL PROTECTED])




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-24 Thread Steve Langasek
On Fri, Feb 24, 2006 at 07:45:16AM +0100, Christian Perrier wrote:

> > After a discussion on IRC, it seems there is no consensus about how 
> > multiarch should be done. Therefore I stop working on that (patches are 
> > still welcome for glibc).

> Is this really the best thing to do?

> Even though there is no consensus (I overread the thread and anyway
> most parts of it fly in the stratosphere from my point of view), I'm
> not sure that abandoning the work is really the answer in this
> situation.

I didn't interpret this as "abandoning" the work.  I think this is the right
point to stop at on glibc right now -- we really need to have support for
multiarch in dpkg an apt before usefully proceeding further.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-23 Thread Christian Perrier

> After a discussion on IRC, it seems there is no consensus about how 
> multiarch should be done. Therefore I stop working on that (patches are 
> still welcome for glibc).

Is this really the best thing to do?

Even though there is no consensus (I overread the thread and anyway
most parts of it fly in the stratosphere from my point of view), I'm
not sure that abandoning the work is really the answer in this
situation.

OK, more talk is needed, maybe use a good BOFH at Debconf is worth it
because controversial issues are better being talked in live
discussions, but I think that the probably good work you did here
should not be left as is.

I'm maybe over-explaining but it seems that you're a little upset here
(correct me if I'm wrong...but IRC excerpts I've seen on #d-d-fr make
me think it)and you're maybe overreacting (no offence intended:
you know me and you know how I respect your work).

In short, please keep up the good work, the discussions and the
like. Debian needs such melting pot of ideas. This will not be the
last time that people won't agree with your ideas or proposals
anyway..:=)


/end of bubulle philosophical thoughts.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-23 Thread Matthias Klose
Bdale Garbee writes:
> On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote:
> 
> > The only change planned is to make libc6-dev-i386 and libc6-i386 provide 
> > a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I 
> > still have to find how to do that cleanly in the debhelper files).
> > 
> > Bdale, do you agree with such a change?
> 
> Yes, I think we can handle that.  It means some small work on ia32-libs
> to stop delivering any conflicting files, but I'm sure we can work that
> out easily enough.  If you want to provide me a patch for ia32-libs that
> does what you want it to do, that would be welcome.

thanks.  with this setup we are able to build our toolchain without
build dependencies on ia32-libs or with packages conflicting with
future multiarch packages (maybe additionally building lib32z1 from
zlib).

Will ia32-libs on ia64 still be supported for the etch release?

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-23 Thread Bdale Garbee
On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote:

> The only change planned is to make libc6-dev-i386 and libc6-i386 provide 
> a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I 
> still have to find how to do that cleanly in the debhelper files).
> 
> Bdale, do you agree with such a change?

Yes, I think we can handle that.  It means some small work on ia32-libs
to stop delivering any conflicting files, but I'm sure we can work that
out easily enough.  If you want to provide me a patch for ia32-libs that
does what you want it to do, that would be welcome.

Bdale


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-23 Thread Aurelien Jarno

Steve Langasek a écrit :

On Thu, Feb 23, 2006 at 10:58:15PM +0100, Aurelien Jarno wrote:



Some update on this, as we have evolved a lot since the last mail.




Bdale Garbee a écrit :


On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote:



Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port 
compliant with the FHS, which is almost impossible given the current 
setup, ie 64-bit libraries in /lib. However, it would make it compliant 
with the part of the FHS which says that alternative libraries have to 
be in (/usr)/lib. And it would make us compatible with other 
distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32.



What sort of value should we assign to achieving that level of
"compatibility" with other distributions before multiarch, where I
expect us to be in the lead and others to be trying to figure out if/how
to be compatible with Debian?

Part of the reason I'm unhappy about the current FHS situation is that
 seems generally to get defined as "32" or "64" and the definition
of what belongs in the unqualified version of the directories feels
inconsistent across architectures.  Part of what I like about our
multiarch strategy is generalizing this to handle more "interesting"
cases like emulated execution environments, etc.  The world just isn't
as simple as 32 vs 64 implies...




I'm inclined to make as few "structural changes" to ia32-libs as
possible pending multiarch implementation.  The reason is that anything
we change is going to make work for people, including work we can't
anticipate or judge the scale of, like users who have laboriously worked
to manually install additional libraries on their systems.  If we're
going to put people through a transition process, I'd prefer it be the
transition to multiarch!




You have been heard! The glibc currently in incoming has a preliminary
multiarch support. It currently looks to librairies in both (/usr)/lib
and (/usr)/lib/$(host-triplet)/. It support additional libraries (like
the current one in multilib), via ldconfig, with /lib/ldconfig/ being
the configuration directory.




Using this it will be possible to add a link from (/usr)/lib64 to the
multiarch directories to be compliant with the FHS. And that let time to
discuss if we want a (/usr)/lib32 or not on amd64 :).




Currently those directories are supported on all architectures, but only
amd64 has files in them, a libc6 for i386. It will be used as a test
architecture before doing the same on other 32/64 bit architectures, as
there are very few packages to changes.



I'm concerned that putting files in /usr/lib/i486-linux-gnu/ may be
premature.  Has thought been given to what this means for the upgrade path
when (...if) dpkg is extended to support installing Arch: i386 multiarch
debs directly on amd64?  I suppose it should just be a Replaces:, but it
still seems like it will be an extra unnecessary transition.



After a discussion on IRC, it seems there is no consensus about how 
multiarch should be done. Therefore I stop working on that (patches are 
still welcome for glibc).


The only change planned is to make libc6-dev-i386 and libc6-i386 provide 
a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I 
still have to find how to do that cleanly in the debhelper files).


Bdale, do you agree with such a change?

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)

2006-02-23 Thread Steve Langasek
On Thu, Feb 23, 2006 at 10:58:15PM +0100, Aurelien Jarno wrote:

> Some update on this, as we have evolved a lot since the last mail.

> Bdale Garbee a écrit :
> >On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote:
> >
> >
> >>Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port 
> >>compliant with the FHS, which is almost impossible given the current 
> >>setup, ie 64-bit libraries in /lib. However, it would make it compliant 
> >>with the part of the FHS which says that alternative libraries have to 
> >>be in (/usr)/lib. And it would make us compatible with other 
> >>distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32.
> >
> >
> >What sort of value should we assign to achieving that level of
> >"compatibility" with other distributions before multiarch, where I
> >expect us to be in the lead and others to be trying to figure out if/how
> >to be compatible with Debian?
> >
> >Part of the reason I'm unhappy about the current FHS situation is that
> > seems generally to get defined as "32" or "64" and the definition
> >of what belongs in the unqualified version of the directories feels
> >inconsistent across architectures.  Part of what I like about our
> >multiarch strategy is generalizing this to handle more "interesting"
> >cases like emulated execution environments, etc.  The world just isn't
> >as simple as 32 vs 64 implies...

> >I'm inclined to make as few "structural changes" to ia32-libs as
> >possible pending multiarch implementation.  The reason is that anything
> >we change is going to make work for people, including work we can't
> >anticipate or judge the scale of, like users who have laboriously worked
> >to manually install additional libraries on their systems.  If we're
> >going to put people through a transition process, I'd prefer it be the
> >transition to multiarch!

> You have been heard! The glibc currently in incoming has a preliminary
> multiarch support. It currently looks to librairies in both (/usr)/lib
> and (/usr)/lib/$(host-triplet)/. It support additional libraries (like
> the current one in multilib), via ldconfig, with /lib/ldconfig/ being
> the configuration directory.

> Using this it will be possible to add a link from (/usr)/lib64 to the
> multiarch directories to be compliant with the FHS. And that let time to
> discuss if we want a (/usr)/lib32 or not on amd64 :).

> Currently those directories are supported on all architectures, but only
> amd64 has files in them, a libc6 for i386. It will be used as a test
> architecture before doing the same on other 32/64 bit architectures, as
> there are very few packages to changes.

I'm concerned that putting files in /usr/lib/i486-linux-gnu/ may be
premature.  Has thought been given to what this means for the upgrade path
when (...if) dpkg is extended to support installing Arch: i386 multiarch
debs directly on amd64?  I suppose it should just be a Replaces:, but it
still seems like it will be an extra unnecessary transition.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature