#include hallo.h
* Goswin von Brederlow [Tue, May 16 2006, 11:55:18PM]:
What do you mean with invasive? Multiarch is designed to be
implemented without disrupting the existing archive or mono-arch
systems at any time. Each package can get converted to multiarch by
itself and once a
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Have you considered employing the alternatives system (or something
similar)? What I'm suggesting is that you'd basically get a /bin64 and a
/bin32, where binaries install
On Thu, May 18, 2006 at 03:23:44AM +0200, Goswin von Brederlow wrote:
But there will be times where the actual source version of debs for
each arch differs. Actualy at every upgarde that happens between arch1
getting unpacked and arch2 getting unpacked as well. Dpkg just has to
handle it in
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Have you considered employing the alternatives system (or something
similar)? What I'm suggesting is that you'd basically get a /bin64
On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Have you considered employing the alternatives system (or
Wouter Verhelst [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Have you considered
Ron Johnson [EMAIL PROTECTED] writes:
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Bill Allombert [EMAIL PROTECTED] writes:
On Sun, May 14, 2006 at 01:19:14AM
On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
Why do you think there's no compatible solution?
Because basicaly all sources assume binaries go to prefix/bin. You
want to break that. Also a lot of scripts expect binaries to
On Tue, May 16, 2006 at 06:02:58PM +0200, Romain Beauxis wrote:
Few things that I see:
-- FUSE goes throught userland - kernel - Userland so it:
** May be an overhead for all /usr/bin calls.
Sure. Every feature has a price. In reality I expect the dentry cache
and the page cache takes care
On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote:
Wait a second. How do you create the dir when the file already exists?
There was quite some talk on linux-kernel about
'every-file-is-a-directory' approaches when Reiserfs 4 was released.
Some said they'd like to see this
On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
Ron Johnson [EMAIL PROTECTED] writes:
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Bill Allombert
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
Why do you think there's no compatible solution?
Because basicaly all sources assume binaries go to prefix/bin. You
want to break
Gabor Gombas [EMAIL PROTECTED] writes:
On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote:
Multiarch (so far) does not allow the same path/file in 2 packages
(with the exception of /usr/share/doc/ files)
Hmm. How do you want to handle one-arch-only binNMUs? binNMUs change
I demand that Gabor Gombas may or may not have written...
[snip]
How do you want to handle one-arch-only binNMUs? binNMUs change
changelog.Debian.gz, so
- you can't upgrade just the architecture that was binNMUed without
changelog.Debian.gz becoming invalid for the other arches
[snip]
I
Ron Johnson [EMAIL PROTECTED] writes:
On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
Ron Johnson [EMAIL PROTECTED] writes:
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Goswin von Brederlow
Darren Salt [EMAIL PROTECTED] writes:
I demand that Gabor Gombas may or may not have written...
[snip]
How do you want to handle one-arch-only binNMUs? binNMUs change
changelog.Debian.gz, so
- you can't upgrade just the architecture that was binNMUed without
changelog.Debian.gz becoming
Peter 'p2' De Schrijver wrote:
Being able to install multiple versions is some use to multiarch, but
could also be used for other things, such if two packages provide the
same binary (git for example).
Or to install multiple 'version 'numbers' of the same package.
The big problem
Scripsit Olaf van der Spek [EMAIL PROTECTED]
Not true. For example, the kernel could be changed to pick the right
Python binary if it sees #!/usr/bin/python.
There is already a hook for doing that that in the kernel; no patching
is required.
See the system calls link(2) and symlink(2). The
On 5/16/06, Henning Makholm [EMAIL PROTECTED] wrote:
Scripsit Olaf van der Spek [EMAIL PROTECTED]
Not true. For example, the kernel could be changed to pick the right
Python binary if it sees #!/usr/bin/python.
There is already a hook for doing that that in the kernel; no patching
is
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
See the system calls link(2) and symlink(2). The (Essential) coreutils
package provides a userspace binary /bin/ln which makes these calls
available to shell scripts.
That's great. Could you tell me how to use those so that
On 5/16/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote:
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
See the system calls link(2) and symlink(2). The (Essential) coreutils
package provides a userspace binary /bin/ln which makes these calls
available to shell scripts.
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/16/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote:
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
See the system calls link(2) and symlink(2). The (Essential) coreutils
package provides a userspace binary /bin/ln which
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote:
I don't care about the implementation details, but if it requires
kernel support, then yes.
How should the kernel (or any other implementation) know which script
requires which python version without the scripts declaring it?
Via
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote:
I don't care about the implementation details, but if it requires
kernel support, then yes.
How should the kernel (or any other implementation) know which script
requires which python
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote:
I don't care about the implementation details, but if it requires
kernel support, then yes.
How should the kernel (or
Olaf van der Spek wrote:
That depends on the implementation but I don't think it's not solvable.
There's a bunch of claims from people who have worked on
multiarch-related problems for a few years. You seem to think those
claims are bogus, so I suggest you write up a solution which does
Pierre Habouzit wrote:
honnestly, please find *ONE* application where alternatives can't solve
your problem, and where upstream design would still allow to have both
instances installed. I've though hard enough, and I've found none.
You might want to have, say, multiple installations of
On 5/16/06, Tollef Fog Heen [EMAIL PROTECTED] wrote:
Olaf van der Spek wrote:
That depends on the implementation but I don't think it's not solvable.
There's a bunch of claims from people who have worked on
multiarch-related problems for a few years. You seem to think those
claims are bogus,
The obvious problem here: The scheme is incompatible with non-multiarched
software. It would at least require a package manager which specialcases
/bin directory, a one-time conversion which moves the binaries, and
some trickery for alternatives. Plus some more things which don't come
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
That's great. Could you tell me how to use those so that script A uses
python 2.3 and script B uses python 2.4 without modifying the scripts?
That's trivial. Create a wrapper that somehow decides which python
version to run and
On Tuesday 16 May 2006 17:53, Gabor Gombas wrote:
However, you can take this idea further: provided you have multiarched
binaries, you could create a small file system using FUSE that generates
such a wrapper on-the-fly based on the requested file name, and you
could mount this file system as
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes:
Being able to install multiple versions is some use to multiarch, but
could also be used for other things, such if two packages provide the
same binary (git for example).
Or to install multiple 'version 'numbers' of the same package.
I don't think so. I see at least a few possible uses for this :
1) have a shared filesystem between machines of multiple architectures
2) test your programs on architectures you don't have by using qemu
It might have its use there but it can't be simply done. The files
from two
Scripsit Olaf van der Spek [EMAIL PROTECTED]
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote:
Here's an idea: store the configuration meta data in the file itself,
say, in the first line, following a comment starting with an exclamation
mark.
This would kill MD5 checksums of
Tollef Fog Heen [EMAIL PROTECTED] writes:
Pierre Habouzit wrote:
honnestly, please find *ONE* application where alternatives can't
solve your problem, and where upstream design would still allow to
have both instances installed. I've though hard enough, and I've
found none.
You might want
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Bill Allombert [EMAIL PROTECTED] writes:
On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
I so far haven't seen any compelling arguments for multiarchifying the
whole
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Pierre Habouzit [EMAIL PROTECTED] wrote:
Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit :
- Why would you want to have both types installed simultaneously
anyway?
For libraries the answer is simple, but multiarch
Eduard Bloch [EMAIL PROTECTED] writes:
#include hallo.h
* Matt Taggart and others [Wed, May 10 2006, 02:00:47AM]:
http://wiki.debian.org/multiarch
Looking at all that I have a simple question: do we need a such kind of
invasive multiarch integration. There only things I have to use which
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes:
Lets say we do add special dirs for binaries and let dpkg manage
them. How would that work with old and new debs mixed together? Should
dpkg move all binaries into subdirs on upgrade once? Should it move
binaries into subdirs when a second
But say you have the old i486 ls installed in /bin/ls and now you
install the new amd64 ls in /bin/ls/x86_64.
Wait a second. How do you create the dir when the file already exists?
dpkg has to specialy handle this case for every package.
That's probably a bit of a problem. But that
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Bill Allombert [EMAIL PROTECTED] writes:
On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
I so far
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote:
The Linux kernel requires a full path for #! scripts. This makes
sense if one considers a #! program to be something that should have
predictable behavior no matter what the user
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/14/06, Michal ÄihaÅ [EMAIL PROTECTED] wrote:
The Linux kernel requires a full path for #! scripts. This makes
One option would be to improve the Linux kernel. :)
And make scripts incompatible with any other unix kernel?
No and that's
Tollef Fog Heen [EMAIL PROTECTED] writes:
Henning Makholm wrote:
In multiarch, the right approach to this particular problem is to
arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python
with $arch chosen (somehow) appropriately for a default python
interpreter.
Apart from
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On 5/14/06, Olaf van der Spek [EMAIL PROTECTED] wrote:
On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote:
sense if one considers a #! program to be something that should have
predictable behavior no matter what the user happens to have in
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/14/06, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
both versions installed, or deal with it via alternatives. They should
be indistinguishable from a users point of view.
Being able to install multiple versions is some use to multiarch,
Jeremy T. Bouse [EMAIL PROTECTED] writes:
I just felt like interjecting after having been reading up on this
tread. The whole multiarch situation is exactly why my workstation
was re-installed with FC5's x86_64 from the old Debian amd64
distro. Someday when Debian has
On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
Henning Makholm wrote:
In multiarch, the right approach to this particular problem is to
arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python
with $arch chosen (somehow) appropriately for a default python
Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit :
- Why would you want to have both types installed simultaneously
anyway?
For libraries the answer is simple, but multiarch applications
simply don't seem useful to me. The solution would be to either
forbid having
Consider for
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/14/06, Michal Čihař [EMAIL PROTECTED] wrote:
The Linux kernel requires a full path for #! scripts. This makes
One option would be to improve the Linux kernel. :)
And make
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Being able to install multiple versions is some use to multiarch, but
could also be used for other things, such if two packages provide the
same binary (git for example).
Or to install multiple 'version 'numbers' of the same package.
On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Bill Allombert [EMAIL PROTECTED] writes:
On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
I so far haven't seen any compelling arguments for multiarchifying the
whole archive including all of */bin.
Personnally I
On 5/15/06, Pierre Habouzit [EMAIL PROTECTED] wrote:
Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit :
- Why would you want to have both types installed simultaneously
anyway?
For libraries the answer is simple, but multiarch applications
simply don't seem useful to me. The
Hi all!
On Monday 15 May 2006 14:15, Olaf van der Spek wrote:
this is a dream. This also need that the application is able to deal
with the fact that it has configuration for the 32 and 64 bits version
coexisting cleanly.
True. Did I say that it would be trivial?
Or even a
#include hallo.h
* Matt Taggart and others [Wed, May 10 2006, 02:00:47AM]:
http://wiki.debian.org/multiarch
Looking at all that I have a simple question: do we need a such kind of
invasive multiarch integration. There only things I have to use which
are not available for native amd64. For
On 5/15/06, Romain Beauxis [EMAIL PROTECTED] wrote:
Hi all!
On Monday 15 May 2006 14:15, Olaf van der Spek wrote:
this is a dream. This also need that the application is able to deal
with the fact that it has configuration for the 32 and 64 bits version
coexisting cleanly.
True.
Le Lun 15 Mai 2006 17:02, Olaf van der Spek a écrit :
On 5/15/06, Romain Beauxis [EMAIL PROTECTED] wrote:
I have a multiarch on my amd64 system only because I want to use
applications that I can't use or does not have the same
functionalities with amd64 (mostly firefox, ooo and mplayer
On 5/15/06, Pierre Habouzit [EMAIL PROTECTED] wrote:
Why would you see many binaries installed from the user point of
view? with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
For example because one user would like to have the absolute latest
version of a certain package
Being able to install multiple versions is some use to multiarch, but
could also be used for other things, such if two packages provide the
same binary (git for example).
Or to install multiple 'version 'numbers' of the same package.
The big problem then is when to install multiple
On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote:
Scripsit Olaf van der Spek [EMAIL PROTECTED]
Goswin von Brederlow [EMAIL PROTECTED] wrote:
That would be total insanity. Just think about the number of scripts
with #!/usr/bin/python in it that would have to be changed. And how
Shouldn't
Hi
On Sun, 14 May 2006 18:32:00 +0200
Olaf van der Spek [EMAIL PROTECTED] wrote:
On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote:
The Linux kernel requires a full path for #! scripts. This makes
One option would be to improve the Linux kernel. :)
And make scripts incompatible with
On 5/14/06, Michal Čihař [EMAIL PROTECTED] wrote:
The Linux kernel requires a full path for #! scripts. This makes
One option would be to improve the Linux kernel. :)
And make scripts incompatible with any other unix kernel?
No and that's not what I said. I'm quite sure there is a
On 5/14/06, Olaf van der Spek [EMAIL PROTECTED] wrote:
On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote:
sense if one considers a #! program to be something that should have
predictable behavior no matter what the user happens to have in his
$PATH.
If the independence is a requirement,
On 5/14/06, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On 5/14/06, Olaf van der Spek [EMAIL PROTECTED] wrote:
On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote:
sense if one considers a #! program to be something that should have
predictable behavior no matter what the user happens
Adam Borowski [EMAIL PROTECTED] writes:
On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
On the other hand, if we continue that thought process we could end up
with all headers and libraries in /usr/share/, which is absurd.
Why? This is exactly what's beautiful, especially if
Olaf van der Spek [EMAIL PROTECTED] writes:
On 5/10/06, Matt Taggart and others [EMAIL PROTECTED] wrote:
For a couple years now a few of us have been talking about an idea called
multiarch. This is a way to seamlessly allow support for multiple different
binary targets on the same system, for
Joe Smith [EMAIL PROTECTED] writes:
Daniel Ruoso [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the
[EMAIL PROTECTED] writes:
There is yet another issue with the $arch portion of the canonical system
name: chips which are upgrades of other chips. For instance, Fedora will
give you 'i686', while Debian will give you 'i486'. This will (and should)
result in two different directories --
Thiemo Seufer [EMAIL PROTECTED] writes:
I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which
provides mappings for multiarch-sensitive programs.
I have dpkg-multiarch for that and other things like cflags, ldflags,
libdir and the like. dpkg-multiarch is used just like
On 5/13/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
That would be total insanity. Just think about the number of scripts
with #!/usr/bin/python in it that would have to be changed. And how
Shouldn't such hard-coded paths be avoided in the long term (anyway)?
would you even change them
I just felt like interjecting after having been reading up on this
tread. The whole multiarch situation is exactly why my workstation was
re-installed with FC5's x86_64 from the old Debian amd64 distro. Someday
when Debian has multiarch I'll switch it back but for now all my 64 bit
machines
Scripsit Olaf van der Spek [EMAIL PROTECTED]
Goswin von Brederlow [EMAIL PROTECTED] wrote:
That would be total insanity. Just think about the number of scripts
with #!/usr/bin/python in it that would have to be changed. And how
Shouldn't such hard-coded paths be avoided in the long term
On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote:
The Linux kernel requires a full path for #! scripts. This makes
sense if one considers a #! program to be something that should have
predictable behavior no matter what the user happens to have in his
$PATH.
The standard idiom
Henning Makholm wrote:
In multiarch, the right approach to this particular problem is to
arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python
with $arch chosen (somehow) appropriately for a default python
interpreter.
Apart from the fact that no multiarch proposals have tried
On Thu, May 11, 2006 at 06:12:42PM -0300, Daniel Ruoso wrote:
And what if dpkg knows about it and handle arch-independant packages in
a different way?
There is nothing dpkg can do. Package-1.0 has a hardcoded reference to
/usr/share/foo/bar (provided by some other package) and expects it to be
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the arch-independent package could be installed at
the same time.
/usr/share/foo/bar can't point to two different files at the same time,
so you can't install multiple package versions
On 5/11/06, Gabor Gombas [EMAIL PROTECTED] wrote:
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the arch-independent package could be installed at
the same time.
/usr/share/foo/bar can't point to two different files at the same
I have created a new page in the wiki to track info and status
http://wiki.debian.org/multiarch
I looked at the upstream standards proposal:
http://lackof.org/taggart/hacking/multiarch/
It's good.
I am particularly pleased by the specification:
The terms arch and os represent the
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote:
The terms arch and os represent the Architecture and Operating System
as defined and provided by config.guess.
Well, config.sub is the one whose function is to provide canonical
names, config.guess might not do so for one reason or another (but it
Matt Taggart and others [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi debian-devel,
For a couple years now a few of us have been talking about an idea called
multiarch. This is a way to seamlessly allow support for multiple
different
binary targets on the same system, for
[EMAIL PROTECTED] wrote:
I have created a new page in the wiki to track info and status
http://wiki.debian.org/multiarch
I looked at the upstream standards proposal:
http://lackof.org/taggart/hacking/multiarch/
It's good.
I am particularly pleased by the specification:
The terms
Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the arch-independent package could be installed at
the same time.
/usr/share/foo/bar can't point to two different files at
On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
On the other hand, if we continue that thought process we could end up
with all headers and libraries in /usr/share/, which is absurd.
Why? This is exactly what's beautiful, especially if EVERYTHING ends up in
/usr/share/ at one day,
Adam Borowski [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
On the other hand, if we continue that thought process we could end up
with all headers and libraries in /usr/share/, which is absurd.
Why? This is exactly
Daniel Ruoso [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the arch-independent package could be installed at
Hi debian-devel,
For a couple years now a few of us have been talking about an idea called
multiarch. This is a way to seamlessly allow support for multiple different
binary targets on the same system, for example running both i386-linux-gnu and
amd64-linux-gnu binaries on the same system
On Wed, 2006-05-10 at 02:00 -0700, Matt Taggart and others wrote:
Hi debian-devel,
For a couple years now a few of us have been talking about an idea called
multiarch. This is a way to seamlessly allow support for multiple different
binary targets on the same system, for example running
On 5/10/06, Matt Taggart and others [EMAIL PROTECTED] wrote:
For a couple years now a few of us have been talking about an idea called
multiarch. This is a way to seamlessly allow support for multiple different
binary targets on the same system, for example running both i386-linux-gnu and
On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote:
Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?
I think that's not going to fly. Just think about the different
On 5/10/06, Gabor Gombas [EMAIL PROTECTED] wrote:
On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote:
Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?
I think that's not
Olaf van der Spek writes...
Does it also allow completely arbitrary combinations to be installed?
We're not sure of this implementation detail yet. But I think...
By default your system won't be multiarch, but the sysadmin can turn on
combinations. The config file for doing this will have
On 5/10/06, Matt Taggart [EMAIL PROTECTED] wrote:
Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?
Read the papers listed in the wiki. The short answer is no, same as it is
today with
On 5/10/06, Olaf van der Spek [EMAIL PROTECTED] wrote:
On 5/10/06, Matt Taggart [EMAIL PROTECTED] wrote:
Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?
Read the papers listed in
93 matches
Mail list logo
