In a couple posts, I noticed that multiarch (or
bi-arch) support was going to be worked on after the
release of sarge. I'd like very much to be able to
use my machine to its potential... can anyone give me
an estimate of when it will be avaliable, or point me
to a status page? Everything I have f
Bob Mitchel <[EMAIL PROTECTED]> writes:
> In a couple posts, I noticed that multiarch (or
> bi-arch) support was going to be worked on after the
> release of sarge. I'd like very much to be able to
> use my machine to its potential... can anyone give me
> an estimate of when it will be avaliable,
On 7/5/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> But you don't realy gain anything by multiarch for amd64. Only 3
> things come to my mind: OpenOffice, Flash support and w32codecs +
> 32bit mplayer. And only OO is in Debian.
The big advantage is binary compatibility with the rest of th
> The current timeline is as follows:
>
> - get security support fully working
> - split the archive by architectures to reduce mirror bandwith
> - add amd64 to sid/etch
> - rebuild and upload all packages from an official buildd
BTW, is there an estimation when amd64 will be added to sid/etch?
R
[..]
> But you don't realy gain anything by multiarch for amd64. Only 3
> things come to my mind: OpenOffice, Flash support and w32codecs +
> 32bit mplayer. And only OO is in Debian.
And OOo 2.0, which is due really soon, will natively support 64-bits
architectures.
> MfG
> Goswin
--
Jérôme Warnier <[EMAIL PROTECTED]> writes:
> [..]
>
>> But you don't realy gain anything by multiarch for amd64. Only 3
>> things come to my mind: OpenOffice, Flash support and w32codecs +
>> 32bit mplayer. And only OO is in Debian.
> And OOo 2.0, which is due really soon, will natively support 64
Thomas Steffen <[EMAIL PROTECTED]> writes:
> On 7/5/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> But you don't realy gain anything by multiarch for amd64. Only 3
>> things come to my mind: OpenOffice, Flash support and w32codecs +
>> 32bit mplayer. And only OO is in Debian.
>
> The big a
On 7/5/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> All current linux distributions are pure64.
That might be a matter of definition. From the user's point of view,
most commercial distributions are multiarch. After all, it is
difficult to sell a "better" distribution that is not even com
On Tuesday 05 July 2005 15:44, Goswin von Brederlow wrote:
> All current linux distributions are pure64. They only differ slightly
> in the amount of 32bit libs preinstalled (what debian has as
> ia32-libs). Multiarch is something that goes way beyond what other
> amd64 distributions have.
>
> Mult
On 16:57, Tue 05 Jul 05, Adam Stiles wrote:
> On Tuesday 05 July 2005 15:44, Goswin von Brederlow wrote:
> > All current linux distributions are pure64. They only differ slightly
> > in the amount of 32bit libs preinstalled (what debian has as
> > ia32-libs). Multiarch is something that goes way be
On Tue, 5 Jul 2005, Adam Stiles wrote:
Binary compatibility is irrelevant at best {every Linux machine already has a
compiler installed} and harmful at worst {Windows has wide-scale binary
compatibility -- and rampant malware}. All that matters is _source_
compatibility: that the same sourc
On Tue, 5 Jul 2005, Goswin von Brederlow wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
Maybe add wine to that list? (Disclaimer, haven't tried it lately)
I actu
On Tue, Jul 05, 2005 at 01:49:08PM -0400, David Wood wrote:
> I actually have a completely different question. I just re-read the
> multi-arch doc and two things jump out: first, it looks extremely
> non-controvertial, i.e. all parties should at least agree it's simple and
> right - there's noth
David Wood wrote:
On Tue, 5 Jul 2005, Goswin von Brederlow wrote:
But you don't realy gain anything by multiarch for amd64. Only 3
things come to my mind: OpenOffice, Flash support and w32codecs +
32bit mplayer. And only OO is in Debian.
Maybe add wine to that list? (Disclaimer, haven't trie
On Tue, 5 Jul 2005, Hugo Mills wrote:
It caused considerable controversy when it was first suggested, and
continued to do so for some time. I suspect that the only reason it
isn't causing much controversy at the moment is because very few
people are doing anything on it right now, so it's not
On Tue, Jul 05, 2005 at 02:12:13PM -0400, David Wood wrote:
> On Tue, 5 Jul 2005, Hugo Mills wrote:
>
> > It caused considerable controversy when it was first suggested, and
> >continued to do so for some time. I suspect that the only reason it
> >isn't causing much controversy at the moment is b
On Tue, 5 Jul 2005, Hugo Mills wrote:
I guess I can only ask... what... on... earth... was the problem?
See below...
Actually, I don't see where you've said what was objectionable about
multiarch.
Well, let's say you want to install a 32-bit xine. That's written
in C, so you have to
On Tue, Jul 05, 2005 at 02:46:44PM -0400, David Wood wrote:
> On Tue, 5 Jul 2005, Hugo Mills wrote:
>
> >>I guess I can only ask... what... on... earth... was the problem?
> >
> > See below...
>
> Actually, I don't see where you've said what was objectionable about
> multiarch.
The whole se
On Tue, 5 Jul 2005, Hugo Mills wrote:
The whole set of problems with the package management.
I don't understand. As far as I could see the problem you raised was what
a (finished) multiarch solves.
As I think I said in my mail, I don't know enough about the
library-building side of it
On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote:
> I don't understand. As far as I could see the problem you raised was what
> a (finished) multiarch solves.
Multiarch was never finished as far as I know.
> I keep saying it. There's a symlink. It's backwards-compatible! There is
> no
On Tue, 5 Jul 2005, Hugo Mills wrote:
On Tue, Jul 05, 2005 at 02:46:44PM -0400, David Wood wrote:
No, you misunderstand. I don't expect that to work. It's obvious that if
you just made the directory structure switch you still have a long way to
go before you can install two different glibc pack
On Tuesday 05 July 2005 19:46, David Wood wrote:
> On Tue, 5 Jul 2005, Hugo Mills wrote:
> >> I guess I can only ask... what... on... earth... was the problem?
> >
> > See below...
>
> Actually, I don't see where you've said what was objectionable about
> multiarch.
>
> > Well, let's say you wa
On Tue, 5 Jul 2005, Lennart Sorensen wrote:
On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote:
I don't understand. As far as I could see the problem you raised was what
a (finished) multiarch solves.
Multiarch was never finished as far as I know.
I'm just trying to understand what
On Tue, 5 Jul 2005, Paul Brook wrote:
Until you have a coherent and generally acceptable plan for how to handle the
hard bits is there any point doing anything (other than as proof-of-concept)?
If you start migrating things before the long-term strategy has been agreed
you risk having to do anot
On 7/5/05, David Wood <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Jul 2005, Adam Stiles wrote:
>
> > Binary compatibility is irrelevant at best {every Linux machine already
> > has a
> > compiler installed} and harmful at worst {Windows has wide-scale binary
> > compatibility -- and rampant malware
On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote:
> I'm just trying to understand what people's objections to multiarch are. I
> didn't understand what Hugo said in answer to that. I meant that it
> sounded like his answers (the problems he brought up) were things that
> multiarch woul
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote:
> > What's the problem? Yes, it will take work to _finish_, but why haven't we
> > even _started_?
>
> Many packages/programs have hardcoded paths in them which will look in
> /usr/lib and
On Tue, 5 Jul 2005, Thomas Steffen wrote:
As programmer I have to say that it should be, if you apply the due
care. However, it will never really work unless you actually test and
debug it. BTW, gcc/gdb does not properly support 64bit on SPARC, just
as a side note on "magically portable".
Magi
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote:
> > I'm just trying to understand what people's objections to multiarch are. I
> > didn't understand what Hugo said in answer to that. I meant that it
> > sounded like his answers (the prob
On Tue, Jul 05, 2005 at 04:25:39PM -0400, Stephen Frost wrote:
> Pfft, give me a break. Guess we'll never move anything ever again.
> That's just not how it works.
No I am sure we will, we just won't claim it is a trivial change.A
Starting to make a pile of symlinks without a plan certainly does
On Tue, 5 Jul 2005, Lennart Sorensen wrote:
The main objection is to change locations of files in a way that is
incompatible with existing software on linux.
But it is not incompatible unless you remove the links - and then you are
no longer following the proposal.
Would they not work prop
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> Of course there is also the issue of how to deal with calling the 32 or
> 64bit version of program x if you have both versions installed. Perhaps
> a helper tool to say run64bit version of x would deal with that, and
> your idea of having symlinks in
* David Wood ([EMAIL PROTECTED]) wrote:
> On Tue, 5 Jul 2005, Lennart Sorensen wrote:
> >>Would they not work properly with the symlink in place?
> >
> >is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib
>
> As I understand it, /usr/lib is a symlink/hardlink/bindmount to
> /usr/
On Tue, 5 Jul 2005, Lennart Sorensen wrote:
No I am sure we will, we just won't claim it is a trivial change.A
It looks trivial to make the new directories and links and _start_.
No such claims about the rest. :)
Starting to make a pile of symlinks without a plan certainly doesn't
seem prod
On 7/5/05, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> > Many packages/programs have hardcoded paths in them which will look in
> > /usr/lib and not in your new directory.
>
> Then they're busted and need to be fixed.
I guess you first have to explai
On 7/5/05, David Wood <[EMAIL PROTECTED]> wrote:
> It took a startlingly small amount of effort in the kernel.
Not sure about small, but it works very well. Yes, if only userspace
was just as easy...
> If we were starting from a blank slate, we can have the rest
> with a tiny change in our namin
On Tue, Jul 05, 2005 at 04:40:17PM -0400, David Wood wrote:
> On Tue, 5 Jul 2005, Lennart Sorensen wrote:
>
> >The main objection is to change locations of files in a way that is
> >incompatible with existing software on linux.
>
> But it is not incompatible unless you remove the links - and then
> -Original Message-
> From: Stephen Frost [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 05, 2005 4:47 PM
> To: Lennart Sorensen
> Cc: David Wood; Hugo Mills; Goswin von Brederlow;
> debian-amd64@lists.debian.org
> Subject: Re: multiarch/bi-arch status (ETA) qu
Thomas Steffen wrote:
> > Multiarch is something that goes way beyond what other
> > amd64 distributions have.
>
> Maybe, but the RedHat package management does support two different
> architectures, and it does it now.
Technically that is "biarch". That is different than "multiarch".
Red Hat ha
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote:
> > What's the reason for having both versions of a given app installed?
> > I'm pretty sure it was decided that was a bad idea and that
> > there wasn't any good use case for it and so we weren't going
> > to try and support it.
> > It just doesn't
Adam Stiles <[EMAIL PROTECTED]> writes:
> On Tuesday 05 July 2005 15:44, Goswin von Brederlow wrote:
>> All current linux distributions are pure64. They only differ slightly
>> in the amount of 32bit libs preinstalled (what debian has as
>> ia32-libs). Multiarch is something that goes way beyond w
[..]
As a start, does anyone know exactly how Solaris does, and can explain
it to whoever is interested in learning about multiarch? Wouldn't that
be interesting?
> Stephen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTE
Gnu-Raiz <[EMAIL PROTECTED]> writes:
> I agree, if source software is unable to be compiled with 64
> bit support then I would suggest that the developer needs to
> get with it. Just look at the hardware that is in the
> channel, most 32 bit cpu's are getting phased out, yes you
> can still get th
Thomas Steffen <[EMAIL PROTECTED]> writes:
> On 7/5/05, David Wood <[EMAIL PROTECTED]> wrote:
>> On Tue, 5 Jul 2005, Adam Stiles wrote:
>>
>> > Binary compatibility is irrelevant at best {every Linux machine already
>> > has a
>> > compiler installed} and harmful at worst {Windows has wide-sc
Thomas Steffen <[EMAIL PROTECTED]> writes:
> The initiative has been taken by other distributions, and I don't see
> a viable alternative to follow their approach. That means /usr/lib for
> 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it
> is close to inevitable.
It is alrea
* J?r?me Warnier ([EMAIL PROTECTED]) wrote:
> [..]
> As a start, does anyone know exactly how Solaris does, and can explain
> it to whoever is interested in learning about multiarch? Wouldn't that
> be interesting?
It's basically biarch... I've got a couple Solaris boxes and I havn't
seen much di
Paul Brook <[EMAIL PROTECTED]> writes:
> On Tuesday 05 July 2005 19:46, David Wood wrote:
>> On Tue, 5 Jul 2005, Hugo Mills wrote:
>> >> I guess I can only ask... what... on... earth... was the problem?
>> >
>> > See below...
>>
>> Actually, I don't see where you've said what was objectionable a
Thomas Steffen <[EMAIL PROTECTED]> writes:
> On 7/5/05, Stephen Frost <[EMAIL PROTECTED]> wrote:
>> * Lennart Sorensen ([EMAIL PROTECTED]) wrote:
>> > Many packages/programs have hardcoded paths in them which will look in
>> > /usr/lib and not in your new directory.
>>
>> Then they're busted and
[EMAIL PROTECTED] (Bob Proulx) writes:
> Thomas Steffen wrote:
>> > Multiarch is something that goes way beyond what other
>> > amd64 distributions have.
>>
>> Maybe, but the RedHat package management does support two different
>> architectures, and it does it now.
>
> Technically that is "biarch
David Wood <[EMAIL PROTECTED]> writes:
> On Tue, 5 Jul 2005, Goswin von Brederlow wrote:
>
>> But you don't realy gain anything by multiarch for amd64. Only 3
>> things come to my mind: OpenOffice, Flash support and w32codecs +
>> 32bit mplayer. And only OO is in Debian.
>
> Maybe add wine to that
Hugo Mills <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 01:49:08PM -0400, David Wood wrote:
>> Am I a bonehead or is it just a matter of moving some directories and
>> symlinks around in etch and then the super-gradual process (many many
>> years if you want) of migrating things from us
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote:
>> I don't understand. As far as I could see the problem you raised was what
>> a (finished) multiarch solves.
>
> Multiarch was never finished as far as I know.
>
>> I keep saying it. There
On Tue, 5 Jul 2005, Thomas Steffen wrote:
The initiative has been taken by other distributions, and I don't see
a viable alternative to follow their approach. That means /usr/lib for
32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it
is close to inevitable.
1) We are not tha
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> On Tue, Jul 05, 2005 at 04:25:39PM -0400, Stephen Frost wrote:
>> Pfft, give me a break. Guess we'll never move anything ever again.
>> That's just not how it works.
>
> No I am sure we will, we just won't claim it is a trivial change.A
>
> Starting
lls; Goswin von
> Brederlow; debian-amd64@lists.debian.org
> Subject: Re: multiarch/bi-arch status (ETA) question
>
> * Latchezar Dimitrov ([EMAIL PROTECTED]) wrote:
> > > What's the reason for having both versions of a given app
> installed?
> > > I'm pre
On Wed, 6 Jul 2005, Kurt Roeckx wrote:
There are not going to be any symlinks at all. There is no need
So, the posted documents are not correct on this (basic, major) point?
And why not have them? Obviously there is a need - to ease migration...
If I may venture a little further, the idea t
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote:
> Do you really do dfs any time you want to do anything on your computer?
Yeah, that's *exactly* the same thing as daring to use apt-get...
Thanks,
Stephen
signature.asc
Description: Digital signature
On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote:
> On Tue, 5 Jul 2005, Adam Stiles wrote:
>
> > Binary compatibility is irrelevant at best {every Linux machine already
> > has a
> > compiler installed} and harmful at worst {Windows has wide-scale binary
> > compatibility -- and rampant mal
David Wood <[EMAIL PROTECTED]> writes:
> On Tue, 5 Jul 2005, Thomas Steffen wrote:
>
>> The initiative has been taken by other distributions, and I don't see
>> a viable alternative to follow their approach. That means /usr/lib for
>> 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly,
Ron Johnson <[EMAIL PROTECTED]> writes:
> On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote:
>> On Tue, 5 Jul 2005, Adam Stiles wrote:
>>
>> > Binary compatibility is irrelevant at best {every Linux machine already
>> > has a
>> > compiler installed} and harmful at worst {Windows has wide-s
David Wood <[EMAIL PROTECTED]> writes:
> On Wed, 6 Jul 2005, Kurt Roeckx wrote:
>
>> There are not going to be any symlinks at all. There is no need
>
> So, the posted documents are not correct on this (basic, major) point?
The only case symlinks are needed is binaries with rpath. Death to
binar
On Wed, 2005-07-06 at 03:27 +0200, Goswin von Brederlow wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote:
> >> On Tue, 5 Jul 2005, Adam Stiles wrote:
[snip]
> >>
> >> 2) We believe that C/C++ is usually magically portable across hardware
Goswin von Brederlow wrote:
> Bob Proulx writes:
> > Red Hat has implemented special case biarch support. Debian has not
> > implemented either but the goal is to implement multiarch.
>
> So under red hat you can actualy do: [whatever dpkg's -i is for rpm]
>
> rpm -i libfoo_i386.rpm
> rpm -i lib
Goswin von Brederlow wrote:
> Thomas Steffen writes:
> > That is the theory, and I do believe in theory... until something more
> > practical comes along. I use Openoffice, Acrobat Reader, Partimage,
> > Mplayer, a bit of Wine, Oracle and sometimes Matlab for Linux. That
> > makes seven application
Goswin von Brederlow wrote:
> Adam Stiles writes:
> > Most current "64 bit" Linux distributions are not pure 64-bit but
> > contain both 32 and 64 bit libraries. In other words, they are
> > multi-arch.
Not multiarch but biarch. Not quite the same thing.
> No. They have ia32-libs preinstalled.
On 7/6/05, Bob Proulx <[EMAIL PROTECTED]> wrote:
[RedHat x86_64]
Thanks for your insight in the RedHat way. With already three OSes
installed on my AMD64, I don't feel like trying another one (an
Solaris 10 would be first anyway), but their approach is definitely
relevant for us. Both as an exampl
On Tue, Jul 05, 2005 at 09:13:47PM -0400, David Wood wrote:
> On Wed, 6 Jul 2005, Kurt Roeckx wrote:
>
> >There are not going to be any symlinks at all. There is no need
>
> So, the posted documents are not correct on this (basic, major) point?
They're not (directly) the way that the Debian
On Tue, Jul 05, 2005 at 04:40:17PM -0400, David Wood wrote:
> But it is not incompatible unless you remove the links - and then you are
> no longer following the proposal.
>
> As I understand it, /usr/lib is a symlink/hardlink/bindmount to
> /usr/lib/i386-linux, not the other way around.
If /us
On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote:
> What's the reason for having both versions of a given app installed?
> I'm pretty sure it was decided that was a bad idea and that there wasn't
> any good use case for it and so we weren't going to try and support it.
> It just doesn'
On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote:
> apt-get install A::amd64;
> Should automatically uninstall the i386 version of A and install the
> amd64 version.
If that's how it is going to behave, I will stick with a chroot for
32bit. Much more useful then. I do have reason to
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote:
> > What's the reason for having both versions of a given app installed?
> > I'm pretty sure it was decided that was a bad idea and that there wasn't
> > any good use case for it and so we
On Tue, Jul 05, 2005 at 04:56:34PM -0400, David Wood wrote:
> Why bother making it hard when you can just make it easy and link the
> whole directory?
You can't make a link to a child of yourself since then the child has no
parent dir to beling to if the parent isn't a directory.
it would work i
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote:
> > apt-get install A::amd64;
> > Should automatically uninstall the i386 version of A and install the
> > amd64 version.
>
> If that's how it is going to behave, I will stick with a chro
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my
pure64. What problems do you have?
The only important thing that distinguishes mplayer from all the other
video players is its ability to use win32 codecs, and thus be actually
useful i
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Getting the toolchain adapted is more important than some trivial mv
commands for libs.
You're right, of course, but I don't understand why we should avoid doing
them. With the new dirs in place and linked from the old locations,
package conver
El mié, 06-07-2005 a las 09:32 -0400, David Wood escribió:
> On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
>
> > Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my
> > pure64. What problems do you have?
>
> The only important thing that distinguishes mplayer from all the other
> video
David Wood <[EMAIL PROTECTED]> writes:
>> can't be a symlink to /usr/lib/i386-linux after all. So if programs on
>
> I don't understand. Why not?
Just try it:
- mkdir /usr/lib/i386-linux
- rm -r /usr/lib
- ln -s /usr/lib/i386-linux /usr/lib
Does that work on your machine?
Matthias
--
To UN
El mié, 06-07-2005 a las 09:11 -0400, Matthias Julius escribió:
> David Wood <[EMAIL PROTECTED]> writes:
>
> >> can't be a symlink to /usr/lib/i386-linux after all. So if programs on
> >
> > I don't understand. Why not?
>
> Just try it:
>
> - mkdir /usr/lib/i386-linux
> - rm -r /usr/lib
> Does
On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote:
you've described. You havn't given any reason why a user would have any
use for it. There are quite a few reasons why trying to do such would
Hm, normally, I wouldn't need a firefox with flash plugin or a
mplayer/xine with old cod
Digesting about 8 things into a single response...
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
You only need dpkg support to utilize it. The design is such that the
debs shall remain compatible to older debian. You just don't get the
multiarch benefits. So apt/dpkg are not realy blocking is
[EMAIL PROTECTED] (Bob Proulx) writes:
> This is where it gets ugly. The /usr/share part overlaps between the
> two packages. As long as the md5sum of a file is the same rpm will
> allow packages to overlap files. (Personally I think that is a bad
> thing and should not have been designed that
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Lennart Sorensen ([EMAIL PROTECTED]) wrote:
>> On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote:
>> > What's the reason for having both versions of a given app installed?
>> > I'm pretty sure it was decided that was a bad idea and that the
Matthias Julius <[EMAIL PROTECTED]> writes:
> David Wood <[EMAIL PROTECTED]> writes:
>
>>> can't be a symlink to /usr/lib/i386-linux after all. So if programs on
>>
>> I don't understand. Why not?
>
> Just try it:
>
> - mkdir /usr/lib/i386-linux
> - rm -r /usr/lib
> - ln -s /usr/lib/i386-linux /u
David Wood <[EMAIL PROTECTED]> writes:
> On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
>
>> Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my
>> pure64. What problems do you have?
>
> The only important thing that distinguishes mplayer from all the other
> video players is its ability t
David Wood <[EMAIL PROTECTED]> writes:
> On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
>
>> Getting the toolchain adapted is more important than some trivial mv
>> commands for libs.
>
> You're right, of course, but I don't understand why we should avoid
> doing them. With the new dirs in place
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Mplayer can play all the common files in 64bit directly except the mov
files of current movie trailers. Anything else mplayer needs w32codecs
for are rather uncommon in my experience.
I find 64-bit unplayable real, wmv and mov files to be by far
Stephan Seitz <[EMAIL PROTECTED]> writes:
> On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote:
>>you've described. You havn't given any reason why a user would have any
>>use for it. There are quite a few reasons why trying to do such would
>
> Hm, normally, I wouldn't need a firefox
David Wood <[EMAIL PROTECTED]> writes:
> On Wed, 6 Jul 2005, Hugo Mills wrote:
>
>> They're not (directly) the way that the Debian multiarch is most
>> likely to go. Unfortunately, the relevant site seems to be down, but
>> take a look at [1], and possibly some of the other (Google cached)
>> fi
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Better not try that with /usr/lib. :)
Well, you always have a backup. Right?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
We are not saying you shouldn't make binaries coinstallable for
multiple archs, we are only saying we won't make this a policy. It is
left to each package maintainer to decide if he wants to make the
multiarch change for his bi
Stephan Seitz <[EMAIL PROTECTED]> writes:
> On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
>>We are not saying you shouldn't make binaries coinstallable for
>>multiple archs, we are only saying we won't make this a policy. It is
>>left to each package maintainer to decide if
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
> Something else ugly... Just curious, why would this break:
>
> mkdir /usr
> mkdir /usr/lib
> ln -s /usr/lib /usr/lib/i386-linux
>
> It's "recursive," but it appears functional...
Yes but now all the i386 files are also in /usr/lib whi
On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
> Because there are so very few plugin using programs that need that at
> all and changing 16K packages just so maybe 20 packages don't have to
> do something special is rather pointless.
>
> Feel free to change mplayer to use /
d; Hugo Mills; Goswin von Brederlow;
debian-amd64@lists.debian.org
Subject: Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote:
> Of course there is also the issue of how to deal with calling the 32
or
> 64bit version of program x if you have both version
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
> On Wed, 6 Jul 2005, Hugo Mills wrote:
>
> > They're not (directly) the way that the Debian multiarch is most
> >likely to go. Unfortunately, the relevant site seems to be down, but
> >take a look at [1], and possibly some of the other
On Wed, 6 Jul 2005, Lennart Sorensen wrote:
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
Something else ugly... Just curious, why would this break:
mkdir /usr
mkdir /usr/lib
ln -s /usr/lib /usr/lib/i386-linux
It's "recursive," but it appears functional...
Yes but now all the
On Wed, Jul 06, 2005 at 06:18:16PM +0200, Goswin von Brederlow wrote:
> David Wood <[EMAIL PROTECTED]> writes:
> > You're right, of course, but I don't understand why we should avoid
> > doing them. With the new dirs in place and linked from the old
> > locations, package conversion can start. Unti
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
> Stephan Seitz <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
> >>We are not saying you shouldn't make binaries coinstallable for
> >>multiple archs, we are only saying w
On Wed, 6 Jul 2005, Hugo Mills wrote:
It's pretty vague, since it doesn't deal with any of the problems
of actually implementing those (fairly high-level) suggestions in any
given package management system.
That doesn't seem to me like something that's wrong.
Are you saying something specif
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
>> Because there are so very few plugin using programs that need that at
>> all and changing 16K packages just so maybe 20 packages don't have to
>> do something special is rather p
1 - 100 of 126 matches
Mail list logo
