24.12.2011 18:21, brian m. carlson пишет:
On Sat, Dec 24, 2011 at 04:54:53PM +0200, Роман Франчук wrote:
Is it possible to get multiarch on debian testing? What can I do in
order to get it?
You need a version of dpkg which is not in the archive yet. You'll have
to build a version fro
24.12.2011 18:21, brian m. carlson пишет:
You need a version of dpkg which is not in the archive yet. You'll have
to build a version from git from the pu/multiarch branch. Be aware that
while some of the infrastructure works just fine, some software (e.g.
aptitude) is buggy.
What troubles
On Sat, Dec 24, 2011 at 04:54:53PM +0200, Роман Франчук wrote:
> Is it possible to get multiarch on debian testing? What can I do in
> order to get it?
You need a version of dpkg which is not in the archive yet. You'll have
to build a version from git from the pu/multiarch branch. Be
Hello, All.
I read that Debian Testing/Unstable and Ubuntu 11.10 support multiarch.
As I read, in order to get multiarch in Ubuntu, I need write
"foreign-architecture i386" to /etc/dpkg/dpkg.cfg
But it does not work in Debian Testing for now. After it dpkg prints
this message:
d
Hello, All.
I read that Debian Testing/Unstable and Ubuntu 11.10 support multiarch.
As I read, in order to get multiarch in Ubuntu, I need write
"foreign-architecture i386" to /etc/dpkg/dpkg.cfg
But it does not work in Debian Testing for now. After it dpkg prints
this message:
d
Giacomo Mulas <[EMAIL PROTECTED]> writes:
> I just noticed that the latest libc6 updates brought us some brand
> new directories such as /etc/ld.so.conf.d/, /lib/ldconfig/... Does this mean
Been there for a while, at least /lib/ldconfig/
> that, unannounced, real multia
I just noticed that the latest libc6 updates brought us some brand
new directories such as /etc/ld.so.conf.d/, /lib/ldconfig/... Does this mean
that, unannounced, real multiarch support the Debian way (or a first step
towards this) is entering unstable? Where can some documentation be
On Mon, May 15, 2006 at 10:42:30AM +0200, Goswin von Brederlow wrote:
> Alexander Samad <[EMAIL PROTECTED]> writes:
>
> > Hi
> >
> > sorry if this email is a bit off topic, but still enough to ask I think.
> >
> > What is the status of multiarch and d
Alexander Samad <[EMAIL PROTECTED]> writes:
> Hi
>
> sorry if this email is a bit off topic, but still enough to ask I think.
>
> What is the status of multiarch and debian (specifically amd64 port).
>
> I like lots of other users have migrated to amd64, I am finding
Hi
sorry if this email is a bit off topic, but still enough to ask I think.
What is the status of multiarch and debian (specifically amd64 port).
I like lots of other users have migrated to amd64, I am finding it a
bit of a pain to get some legacy software and even new stuff to work on
my
gt;> >>I've been working on wrappers for apt and dpkg-deb to get some
>> >>resemblance of multiarch that can still make it for etch. The first
>> >>thing I made to work is installing amd64 kernels on i386 and anyone
>> >>
>> >>
>> &
On Wed, Apr 26, 2006 at 01:01:57AM +0100, Jo Shields wrote:
> [EMAIL PROTECTED] wrote:
>
> >On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
> >
> >
> >>Hi,
> >>
> >>I've been working on wrappers for apt and dpkg-deb
[EMAIL PROTECTED] wrote:
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch. The first
thing I made to work is installing amd64 kernels on i38
On Tue, Apr 25, 2006 at 07:02:35PM +0200, Goswin von Brederlow wrote:
> Hi,
>
> I've been working on wrappers for apt and dpkg-deb to get some
> resemblance of multiarch that can still make it for etch. The first
> thing I made to work is installing amd64 kernels on i386 and a
Hi,
I've been working on wrappers for apt and dpkg-deb to get some
resemblance of multiarch that can still make it for etch. The first
thing I made to work is installing amd64 kernels on i386 and anyone
interested is welcome to try a very alpha release:
ftp://mrvn.homeip.net/apt-get-mult
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote:
>> So I guess the final answer is either we figure out
>> a preprocessor based patch which makes the necessary
>> adjustments for 64bit archs, and leaves the code basically
>> the same for 32
On Wed, Dec 14, 2005 at 08:36:08AM -0200, Eduardo M KALINOWSKI wrote:
> I'd strongly advise the author to avoid such hacks and write proper
> portable code. Unless he wants his package to be another OpenOffice.org.
It already is another openoffice.org, just not quite as big. :)
Len Sorensen
--
On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote:
> Yes, thanks for the nice demonstration, so memcpy
> is not really the problem, however, changing the amount of bits
> used for a single slot is going to be... QUoting the author,
> going to more than 64bit would be a loss of performance
Mario Lang wrote:
[EMAIL PROTECTED] (Lennart Sorensen) writes:
On Tue, Dec 13, 2005 at 01:53:04PM +0100, Mario Lang wrote:
SuperCollider is for some reason I am going to explain below a bit
strange when it comes to porting it to AMD64:
SC consists of two separate programs, the synthe
Mario Lang wrote:
>Yes, thanks for the nice demonstration, so memcpy
>is not really the problem, however, changing the amount of bits
>used for a single slot is going to be... QUoting the author,
>going to more than 64bit would be a loss of performance, going
>to less than 64bit would be a loss o
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> Mario Lang wrote:
>
>> In this specific case, that is a very hypothetical thesis... I cant really
>> imagine an arch which does say 80bit or 128bit floating point math
>> faster than 64bit...
>
> M68K comes to mind, I think that might do 80bit FP f
Mario Lang wrote:
> In this specific case, that is a very hypothetical thesis... I cant really
> imagine an arch which does say 80bit or 128bit floating point math
> faster than 64bit...
M68K comes to mind, I think that might do 80bit FP faster than it does
64-bit (because the FPU does 80-bit).
and install this stuff by hand, simply build the
>> server on the system as usual, and build the language client in a sid-ia32
>> chroot, do the ld.so.conf magic and symlink sclang. That works
>> nicely.
>> However, I am kind of wondering how to solve this properly
>> whe
nstall this stuff by hand, simply build the
> server on the system as usual, and build the language client in a sid-ia32
> chroot, do the ld.so.conf magic and symlink sclang. That works
> nicely.
> However, I am kind of wondering how to solve this properly
> when it comes to packaging
supercollider?
I am not up-to-date with how multiarch is exactly ment to work
these days, would it fit this kind of application?
If so, whats the proper way to do it, and can this already be done
with the infrastructure currently in amd64 sid?
--
CYa,
Mario
--
To UNSUBSCRIBE, email to [EMAIL
Goswin von Brederlow wrote:
I posted a few patches to the BTS adding the multiarch dirs to the
toolchain without breaking existing practices. Once those are added we
can start patching packages to use those new dirs.
I don't want to start and maintain a second amd64 archive (and extra
pa
"Matthew A. Nicholson" <[EMAIL PROTECTED]> writes:
> Are there any new updates on multiarch or is it still just a purposal?
> I say we organize a team to get multiarch working and stop sitting on
> our hands.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTEC
Are there any new updates on multiarch or is it still just a purposal?
I say we organize a team to get multiarch working and stop sitting on
our hands.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, Jul 08, 2005 at 08:23:10PM +0200, Goswin von Brederlow wrote:
> > $ apt-cache show liferea-mozilla
> > [...]
> > Depends: liferea (= 0.9.1-1), mozilla-browser, [...]
> >
> > Gabor
>
> Does that dlopen mozilla?
Looking at the /proc/.../maps file it does.
Gabor
--
-
ies use /usr/lib/arch-os/ to make libs differ between
>> > archs.
>>
>>That's not _entirely_ true. In Tollef's multiarch proposal, files
>> in /usr/share/doc/ can indeed overlap between packages with
>> precisely the same name differing only
On 7/8/05, Miroslav Maiksnar <[EMAIL PROTECTED]> wrote:
> Wouldn't be better have /usr/share/doc/// directories? No
> files will be overlapping and all libs will have it's own copyright and
> README files (which may differ between different arch-os combinations).
No, I don't think so. The idea of
hs.
>
>That's not _entirely_ true. In Tollef's multiarch proposal, files
> in /usr/share/doc/ can indeed overlap between packages with
> precisely the same name differing only in architecture. My preliminary
> patches to dpkg supported that behaviour.
Wouldn't be better
; ., placing the 32bit libs in /lib
>> to preserve rpath for both 32bit and 64bit.
>
> So, if I can go back to my original question: what are the blockers
> for a package maintainer who wants to get started with multiarch? It
> sounds like just some symlinks in base packages
Multi-arch: no" given that
it has so many plugins and is very high in dependency trees.
This is one thing that is unsaid or unclear in the multiarch
proposal. Packages can have one of 3 types:
1. Multi-arch: yes
This is a library package. Any number of architectures of this
package can
GOMBAS Gabor <[EMAIL PROTECTED]> writes:
> On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote:
>
>> Configure scripts have sometimes hardcoded paths to /usr/lib.
>
> And /usr/include. Don't forget that some packages install
> architecture-specific header files under /usr/include.
gt;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 binary too or not and
the blockers for a
package maintainer who wants to get started with multiarch? It sounds like
just some symlinks in base packages are all that need to change...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> If we could ignore rpath problems, then moving everything to an arch dir
> under each lib dir would take care of the libs since the ld loader can
> handle the new locations. Building software may or may not work since
> configure scripts might get co
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Bob Proulx ([EMAIL PROTECTED]) wrote:
>> Goswin von Brederlow wrote:
>> > Hugo Mills <[EMAIL PROTECTED]> writes:
>> > > How? You can't install your two multiarch versions of libvorbis
>> > &g
[EMAIL PROTECTED] (Bob Proulx) writes:
> Thomas Steffen wrote:
>> The better way to do it is to have three (sub)packages: i386, x86_64
>> and shared. That is a bit like -common and -bin, but the packages
>> differ only in architecture, not in the name. Imho that is the way to
>> go.
>>
>> However
On Thu, Jul 07, 2005 at 05:32:45PM +0200, Thomas Steffen wrote:
> I wouldn't call that just fine. Setting the environment variables
> means that you break any 64bit process that Openoffice might want to
> spawn, which is a certain way to get really strange bugs. I bet that
> printing using kprinte
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
> Also programs don't depend on something like galeon (i hope).
$ apt-cache show liferea-mozilla
[...]
Depends: liferea (= 0.9.1-1), mozilla-browser, [...]
Gabor
--
--
On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote:
> Configure scripts have sometimes hardcoded paths to /usr/lib.
And /usr/include. Don't forget that some packages install
architecture-specific header files under /usr/include.
> Libtool adds rpath if libraries are not in defa
On 7/7/05, GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> Well, Vmware runs just fine without any kind of chroot.
Yes, I did get the test version of VMware running, but it was not
without issues.
> OOo also runs
> fine if you just _install_ it in a chroot but call it from the outside
> (well, you nee
On Thu, 7 Jul 2005, Bob Proulx wrote:
I really don't like needing to change the package names to be uniquely
named. I think for multiarch to really work in Debian then dpkg needs
to have a split brain where the architecture specific packages are
tracked separately.
I think he just mean
* Bob Proulx ([EMAIL PROTECTED]) wrote:
> Goswin von Brederlow wrote:
> > Hugo Mills <[EMAIL PROTECTED]> writes:
> > >How? You can't install your two multiarch versions of libvorbis
> > > without a hacked package manager that understands how to do it.
&
Goswin von Brederlow wrote:
> Hugo Mills <[EMAIL PROTECTED]> writes:
> >How? You can't install your two multiarch versions of libvorbis
> > without a hacked package manager that understands how to do it.
>
> You name packages lib32foo and lib64foo or somethi
ic area. Not sure of the
underlying details.
> > depends upon 'libm.so.6()(64bit)' fine.
>
> Now that '(64bit)' is something they had to add for biarch support.
I believe that is the only addition for biarch support. I can't see
anything else different from the
Thomas Steffen wrote:
> The better way to do it is to have three (sub)packages: i386, x86_64
> and shared. That is a bit like -common and -bin, but the packages
> differ only in architecture, not in the name. Imho that is the way to
> go.
>
> However, if you look closer, you find that both approac
On Tue, Jul 05, 2005 at 05:26:46PM +0200, Thomas Steffen wrote:
> No, for all practical purposes you do not have that. I could not get a
> single third part binary to work without a chroot. And recommending a
> chroot is just a different way of saying that it is not supported.
Well, Vmware runs j
On Thu, Jul 07, 2005 at 04:10:46AM +0200, Goswin von Brederlow wrote:
> That why you read Toleffs proposal for multiarch for debian fo details.
>
> You name packages lib32foo and lib64foo or something non
> conflicting. Or you use the multiarch patch for dpkg.
How about mips?
Hugo Mills <[EMAIL PROTECTED]> writes:
> 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. Unfortunat
rything else.
>>
>>
>> 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
you saying something specific in Debian wouldn't work, and couldn't be
elegantly made to work, with the scheme? Reading it, I can't see what that
would be - but that's not saying much, that's why I'm asking.
Sure you can. Just test them.
How? You can't ins
gt;>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 binary too or not and nearly every one will
> >>not.
> >
> > All right, this is a
cations, package conversion can start. Until then, the process waits
> > to start. Why wait?
>
> We shouldn't. We just have to test this very carefully or the fallout
> of a bad upload will create too much oposition to including multiarch
> patches and slow us down overall.
&g
With links in place, ld would not even need to be changed except "at the
end" or in prerelease multiarch systems (although, maybe, why wait?); the
idea is that nothing would, in fact, need to change, until you are ready,
while you can simultaneously prepare your packages for the new
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], a
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
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 binary too or not and nearly every one will
> not.
If you did allow it, you could almost have
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
tony mancill <[EMAIL PROTECTED]> writes:
> Matthias Julius wrote:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>>>Better not try that with /usr/lib. :)
>>
>> Well, you always have a backup. Right?
>
>
>
> It's not the backup that'll kill you, it's having a dynamically linked
> copy of "l
to each package maintainer to decide if he wants to make the
>>multiarch change for his binary too or not and nearly every one will
>>not.
>
> All right, this is a solution I can live with. Until now I thought,
> that it would be impossible, even with multiarch, to install
Matthias Julius wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>>Better not try that with /usr/lib. :)
>
> Well, you always have a backup. Right?
It's not the backup that'll kill you, it's having a dynamically linked
copy of "ln" that needs something in /usr/lib/ that'll drive you c
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 chan
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]
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 possib
> Hm, normally, I wouldn't need a firefox with flash plugin or a
> mplayer/xine with old codecs, so I would use the 64bit version. But
> sometimes I need flash, the realplayer or old video codecs.
> Of course I could build a chroot, but then I wouldn't need multiarch.
>
> So
the most
common media I run across, but of course, it's not a scientific survey...
But if you do need w32codecs then just stick with a 32bit
mplayer. With multiarch that will be just "apt-get install mplayer-686
w32codecs". Till then it means a chroot or some manual fiddling.
Q
> doing them. With the new dirs in place and linked from the old
> locations, package conversion can start. Until then, the process waits
> to start. Why wait?
We shouldn't. We just have to test this very carefully or the fallout
of a bad upload will create too much oposition t
> video players is its ability to use win32 codecs, and thus be actually
> useful in the real world. Does not work in pure64, except in
> chroot. I'm not even saying multiarch would help solve this problem (I
> don't know), just commenting generally.
>
> Wine: interest
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
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
version were installed it would meet
> the dependency of that particular package but of course not be
> sufficient to the needs of the 64-bit program. Of course this is
> simply a single package bug but illustrative.
Now that '(64bit)' is something they had to add for biarch
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 blo
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
1) We are not that compatible to begin with
In what way? We follow LSB and such.
Different "baseline" libraries, different _available_, _packaged_
libraries, different compiler versions, different directory structures
(for instance, important
r/xine with old codecs, so I would use the 64bit version. But
sometimes I need flash, the realplayer or old video codecs.
Of course I could build a chroot, but then I wouldn't need multiarch.
So why don't create /usr/bin/i386 and /usr/bin/amd64 and populate
/usr/bin with symlinks to the
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
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: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
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
in the real world. Does not work in pure64, except in chroot. I'm
not even saying multiarch would help solve this problem (I don't know),
just commenting generally.
Wine: interesting. I'll (optimistically) take another look.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
* 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 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
sage in libraries needs to be split out in a -common package
> > for that library. This isn't an issue for programs because we're not
> > interested in supporting the unjustified case for having the same
> > program both 32bit and 64bit at the same time.
>
> If we don't then I consider multiarch very broken.
That's nice.
Stephen
signature.asc
Description: Digital signature
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
ms because we're not
> interested in supporting the unjustified case for having the same
> program both 32bit and 64bit at the same time.
If we don't then I consider multiarch very broken.
Len Sorensen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d myself quite badly to have been
> misunderstood on this so much.
>
> I am not saying that one starts multiarch and immediately pretends its
> finished. Only that one can start, without breaking anything... so why not
> start?
>
> Why not make /usr/lib/i386-linux and make the
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)
files in [2].
> And why not have them? Obviously there is a need - to ease migration...
>
> If I may venture
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
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
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:
> 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]
>
>
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
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
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 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,
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
* 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 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
1 - 100 of 162 matches
Mail list logo
