Clint Adams 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, with 64-bit
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.
Tha
Hector Oron 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 workarrounds that it is w
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
Steve Langasek 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 of inst
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 soft
Stephen Gran writes:
> This one time, at band camp, Goswin von Brederlow said:
>> Stephen Gran 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
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 ext
On Tue, 2009-03-17 at 11:52 +0100, Goswin von Brederlow wrote:
> Ian Campbell 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
This one time, at band camp, Goswin von Brederlow said:
> Stephen Gran 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
Stephen Gran 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 repo
Ian Campbell 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 /lib/ld-li
Aurelien Jarno writes:
> On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
>> Aurelien Jarno writes:
>>
>> > Goswin von Brederlow a écrit :
>> >> Aurelien Jarno writes:
>> Note that apt-cross and ia32-apt-get can be used already to install
>> multiarch with a certain amount
[ 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/li
On Mon, Mar 16, 2009 at 10:45:32PM +0100, Marco d'Itri wrote:
> On Mar 16, Mike Hommey 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.
>
On Mar 16, Mike Hommey 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 really, because
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 archite
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno writes:
>
> > Goswin von Brederlow a écrit :
> >> Aurelien Jarno 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
]] 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 UNSUBSCRIBE
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 architectu
Roger Leigh writes:
> On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
>> Aurelien Jarno writes:
>>
>> > Goswin von Brederlow a écrit :
>> >> Aurelien Jarno writes:
>> >>
>> >>> One of the goal of multiarch is to avoid having packages containing
>> >>> binaries of a diffe
m...@linux.it (Marco d'Itri) writes:
> On Mar 16, Simon Richter 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 sparc/sparc64, po
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 Ca
m...@linux.it writes:
> On Mar 16, Simon Richter 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 somebod
Mike Hommey 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 on amd64 systems.
>s/proprietary// ; ther
On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri wrote:
> On Mar 16, Simon Richter 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.
>
On Mar 16, Simon Richter 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 why a
multiar
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 Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno writes:
>
> > Goswin von Brederlow a écrit :
> >> Aurelien Jarno writes:
> >>
> >>> One of the goal of multiarch is to avoid having packages containing
> >>> binaries of a different architecture than the one
Aurelien Jarno writes:
> Goswin von Brederlow a écrit :
>> Aurelien Jarno 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 installi
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
Steve Langasek writes:
> On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
>> Josselin Mouette 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
Goswin von Brederlow a écrit :
> Aurelien Jarno 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-lin
On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
> Josselin Mouette 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
Aurelien Jarno 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 FHS) to us
Josselin Mouette 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 year). Then ac
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.
>
>
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 newe
Steve Langasek 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 availab
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 custo
]] 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 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
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
Steve Langasek writes:
> On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
>> Steve Langasek 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
On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
> Steve Langasek 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 p
Steve Langasek 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 Replaces: lib32
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
> Conf
Steve Langasek 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 multiarch pa
Steve Langasek 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 gcc/binutils if we
Clint Adams 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 code does not bre
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 th
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
> stuf
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
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 usi
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
>
]] 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 stuf
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
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, 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
59 matches
Mail list logo
