Clint Adams sch...@debian.org writes:
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in /usr/lib on this architecture,
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs
in /usr/lib64.
That
Hector Oron hector.o...@gmail.com writes:
Hello Goswin et al,
IMHO, the things you are talking about are quite nice. They way it
works sounds to me a little complex, that it is very close to the idea
of crosscompiling, as the *right way*, as opposed to accumulate dirty
hacks and
[ Just chiming in, but I have not read the whole thread. ]
On Mon, 16 Mar 2009, Aurelien Jarno wrote:
3) Where should dpkg put maintainer scripts and package data?
Suggestions:
/var/lib/dpkg/info/i386/libc6.list
/var/lib/dpkg/info/i386-libc6.list
/var/lib/dpkg/info/libc6/i386.list
Aurelien Jarno aurel...@aurel32.net writes:
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
Note that apt-cross and ia32-apt-get can be used
Ian Campbell i...@hellion.org.uk writes:
On Mon, 2009-03-16 at 14:36 +0100, Goswin von Brederlow wrote:
Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
due to the dynamic linker
Really? I thought the i386 dynamic linker was /lib/ld-linux.so.2 and the
64 bit one was
Stephen Gran sg...@debian.org writes:
This one time, at band camp, Goswin von Brederlow said:
1) How to specify an arch in sources.list?
Don't. Specify it in apt.conf
Suggestion:
deb [arch=i386,amd64] http://ftp.debian.org sid main
APT::Arches i386,amd64
Or something.
What if one
This one time, at band camp, Goswin von Brederlow said:
Stephen Gran sg...@debian.org writes:
This one time, at band camp, Goswin von Brederlow said:
1) How to specify an arch in sources.list?
Don't. Specify it in apt.conf
Suggestion:
deb [arch=i386,amd64] http://ftp.debian.org
On Tue, 2009-03-17 at 11:52 +0100, Goswin von Brederlow wrote:
Ian Campbell i...@hellion.org.uk writes:
On Mon, 2009-03-16 at 14:36 +0100, Goswin von Brederlow wrote:
Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
due to the dynamic linker
Really? I thought
Hi,
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software on amd64 systems.
Most applications don't really need the
Stephen Gran sg...@debian.org writes:
This one time, at band camp, Goswin von Brederlow said:
Stephen Gran sg...@debian.org writes:
This one time, at band camp, Goswin von Brederlow said:
1) How to specify an arch in sources.list?
Don't. Specify it in apt.conf
Suggestion:
deb
On Tue, Mar 17, 2009 at 06:29:08PM +0100, Simon Richter wrote:
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software
Steve Langasek vor...@debian.org writes:
On Tue, Mar 17, 2009 at 06:29:08PM +0100, Simon Richter wrote:
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case
Hello Goswin et al,
IMHO, the things you are talking about are quite nice. They way it
works sounds to me a little complex, that it is very close to the idea
of crosscompiling, as the *right way*, as opposed to accumulate dirty
hacks and workarrounds that it is what most embedded distros do out
Josselin Mouette j...@debian.org writes:
Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
Say you have acrobat reader installed which depend on ia32-libs-gtk.
You also have libgtk2.0 (i386) installed with a newer version that
breaks acrobat reader (like it did last
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to change packages installing files to
| /emul/ia32-linux (which violates the
On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
Josselin Mouette j...@debian.org writes:
Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
Say you have acrobat reader installed which depend on ia32-libs-gtk.
You also have libgtk2.0 (i386)
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to change packages installing files to
|
Steve Langasek vor...@debian.org writes:
On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
Josselin Mouette j...@debian.org writes:
Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
Say you have acrobat reader installed which depend on
Hi,
On Fri, Mar 13, 2009 at 11:27:47PM -0700, Steve Langasek wrote:
On Fri, Mar 13, 2009 at 05:57:32PM +0100, Simon Richter wrote:
That is actually beneficial if we wanted to merge both architectures into
one, which would IMO be the sanest thing to do,
IMO that's not a sane thing to do at
Aurelien Jarno aurel...@aurel32.net writes:
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
One of the goal of multiarch is to avoid having packages containing
binaries of a different
On Mon, Mar 16, 2009 at 01:55:40PM +, Roger Leigh wrote:
We are not using multiarch paths in Debian, so this has never happens.
When using standard /usr/lib paths, people are expecting that the paths
collide. When using multiarch they do not expect that, as it the goal of
On Mar 16, Simon Richter s...@debian.org wrote:
Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
and s390/s390x. That would allow us to get rid of a lot of specianl cases,
including the hack for libc6-386.
I think it would be very helpful if somebody could summarize
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri m...@linux.it wrote:
On Mar 16, Simon Richter s...@debian.org wrote:
Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
and s390/s390x. That would allow us to get rid of a lot of specianl cases,
including the
Mike Hommey wrote:
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri m...@linux.it wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software on amd64 systems.
s/proprietary//
m...@linux.it writes:
On Mar 16, Simon Richter s...@debian.org wrote:
Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
and s390/s390x. That would allow us to get rid of a lot of specianl cases,
including the hack for libc6-386.
I think it would be very helpful if
On Mon, 2009-03-16 at 14:36 +0100, Goswin von Brederlow wrote:
Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
due to the dynamic linker
Really? I thought the i386 dynamic linker was /lib/ld-linux.so.2 and the
64 bit one was /lib/ld-linux-x86-64.so.2.
Ian.
--
Ian
m...@linux.it (Marco d'Itri) writes:
On Mar 16, Simon Richter s...@debian.org wrote:
Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
and s390/s390x. That would allow us to get rid of a lot of specianl cases,
including the hack for libc6-386.
I don't see
Roger Leigh rle...@codelibre.net writes:
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
One of the goal of multiarch is to avoid having
This one time, at band camp, Goswin von Brederlow said:
1) How to specify an arch in sources.list?
Don't. Specify it in apt.conf
Suggestion:
deb [arch=i386,amd64] http://ftp.debian.org sid main
APT::Arches i386,amd64
Or something.
2) How to specify a package including the architecture?
]] Stephen Gran
| Put another way, I can't think of a valid use for an amd64 binary
| depending on a ppc32 binary.
Package: foo
Depends: sed
(sed is Essential: yes, but I think you get the point.)
--
Tollef Fog Heen
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73
--
To
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
On Wed, Mar 11, 2009 at
This one time, at band camp, Tollef Fog Heen said:
]] Stephen Gran
| Put another way, I can't think of a valid use for an amd64 binary
| depending on a ppc32 binary.
Package: foo
Depends: sed
(sed is Essential: yes, but I think you get the point.)
I don't see what the architecture of
On Mar 16, Mike Hommey m...@glandium.org wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software on amd64 systems.
s/proprietary// ; there you have your obvious case.
Not
On Mon, Mar 16, 2009 at 10:45:32PM +0100, Marco d'Itri wrote:
On Mar 16, Mike Hommey m...@glandium.org wrote:
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software on amd64
Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
Say you have acrobat reader installed which depend on ia32-libs-gtk.
You also have libgtk2.0 (i386) installed with a newer version that
breaks acrobat reader (like it did last year). Then acrobat reader
will use the newer
On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to change packages installing files to
| /emul/ia32-linux (which violates the FHS) to use
| /usr/lib32 instead.
Could we
On Fri, Mar 13, 2009 at 05:57:32PM +0100, Simon Richter wrote:
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in
]] Goswin von Brederlow
| Is that even true? /lib32 and /usr/lib32 are system library paths
| while the multiarch dirs are custom paths added via
| /etc/ld.so.conf.d/x86_64-linux-gnu.conf. I think they come last.
While I haven't investigated the load order, my
/lib/ld-linux-x86-64.so.2 seems to
On Fri, Mar 13, 2009 at 12:05:42PM +0100, Goswin von Brederlow wrote:
- multiarch will supersede all previous biarch implementations
- multiarch will be before biarch in the search path
Is that even true? /lib32 and /usr/lib32 are system library paths
while the multiarch dirs are custom
Steve Langasek vor...@debian.org writes:
On Fri, Mar 13, 2009 at 12:05:42PM +0100, Goswin von Brederlow wrote:
Taken together, this guarantees the newer libs would always be found before
the older libs, so there's no need to do extra special-casing for those
libs
that were previously
Steve Langasek vor...@debian.org writes:
On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:
What transitional issues is that going to cause us if and when
Hi,
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs
in /usr/lib64.
Clint Adams sch...@debian.org writes:
It may be time to change packages installing files to
/emul/ia32-linux (which violates the FHS) to use
/usr/lib32 instead.
NO NO NO NO NO NO NO NO.
It is high time to change to the multiarch dir. For that gcc needs to
be fixed first so compiling 32bit
Steve Langasek vor...@debian.org writes:
On Wed, Mar 11, 2009 at 10:50:23PM +, Clint Adams wrote:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
Could we pretty please use the multiarch paths here if we start moving
stuff around? We're going to need to patch
Steve Langasek vor...@debian.org writes:
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to change packages installing files to
| /emul/ia32-linux (which violates the FHS) to use
| /usr/lib32 instead.
Could we pretty please use the
On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:
What transitional issues is that going to cause us if and when multiarch
becomes generally available, if biarch packages start using the path now?
libfoo i386 then needs Replaces: lib32foo. But it already needs
Steve Langasek vor...@debian.org writes:
On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:
What transitional issues is that going to cause us if and when multiarch
becomes generally available, if biarch packages start using the path now?
libfoo i386 then needs
On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:
What transitional issues is that going to cause us if and when multiarch
becomes generally available, if
It may be time to change packages installing files to
/emul/ia32-linux (which violates the FHS) to use
/usr/lib32 instead.
I believe the affected packages are
fakechroot
fakeroot
gnu-efi
ia32-libs
ia32-libs-gtk
lib32asound2
lib32asound2-dev
lib32bz2-1.0
lib32bz2-dev
lib32ffi5
lib32ffi-dev
On Wed, Mar 11, 2009 at 05:46:31PM +, Clint Adams wrote:
glibc will need to change first, and the remaining
packages will be broken until they are changed as well.
Do you have a date for the glibc change?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Wed, Mar 11, 2009 at 05:46:31PM +, Clint Adams wrote:
It may be time to change packages installing files to
/emul/ia32-linux (which violates the FHS) to use
/usr/lib32 instead.
/usr/lib32 isn't exactly FHS either, but it's better than
/emul/ia32-linux
Will this also change for ia64?
On Wed, 11 Mar 2009 21:12:31 +0100, Kurt Roeckx wrote:
On Wed, Mar 11, 2009 at 05:46:31PM +, Clint Adams wrote:
It may be time to change packages installing files to
/emul/ia32-linux (which violates the FHS) to use
/usr/lib32 instead.
/usr/lib32 isn't exactly FHS either, but it's
]] Clint Adams
| It may be time to change packages installing files to
| /emul/ia32-linux (which violates the FHS) to use
| /usr/lib32 instead.
Could we pretty please use the multiarch paths here if we start moving
stuff around? We're going to need to patch gcc/binutils if we're to
compile
On Thu, Mar 12, 2009 at 04:54:51AM +1100, Aníbal Monsalve Salazar wrote:
Do you have a date for the glibc change?
I was hoping for pretty soon after a thorough discussion.
On Wed, Mar 11, 2009 at 09:12:31PM +0100, Kurt Roeckx wrote:
/usr/lib32 isn't exactly FHS either, but it's better than
On Wed, Mar 11, 2009 at 05:46:31PM +, Clint Adams wrote:
It may be time to change packages installing files to
/emul/ia32-linux (which violates the FHS) to use
/usr/lib32 instead.
While I hate /emul with a passion (another top level dir filling up my
root filesystem), shouldn't we be using
On Wed, Mar 11, 2009 at 10:50:23PM +, Clint Adams wrote:
On Wed, Mar 11, 2009 at 09:12:31PM +0100, Kurt Roeckx wrote:
/usr/lib32 isn't exactly FHS either, but it's better than
/emul/ia32-linux
Will this also change for ia64? As far as I know, there that path
is hardcoded in the
On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
]] Clint Adams
| It may be time to change packages installing files to
| /emul/ia32-linux (which violates the FHS) to use
| /usr/lib32 instead.
Could we pretty please use the multiarch paths here if we start moving
stuff
On Wed, Mar 11, 2009 at 10:50:23PM +, Clint Adams wrote:
On Wed, Mar 11, 2009 at 05:36:26PM -0400, Michael S. Gilbert wrote:
Is this necessary? There are already softlinks set up:
/usr/lib32-/emul/ia32-linux/usr/lib and /lib32-/emul/ia32-linux/lib.
It's not necessary any more than
60 matches
Mail list logo
