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:
>> >>
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 sys
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
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 i
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
#include
* 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 substantial nu
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.
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/0
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
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
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 /bin. You
>> want t
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
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 fea
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 c
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 /bin. You
> want to break that. Also a lot of scripts expect binaries
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, Ma
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 w
>
> 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 tha
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 s
Eduard Bloch <[EMAIL PROTECTED]> writes:
> #include
> * 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 whi
"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
"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 multiarchify
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.
>
> Y
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 ch
> > 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 t
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 p
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
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 an
>
> 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 co
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 bogu
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 apach
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 all
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
"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
>> req
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?
"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
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 scr
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 th
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
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). T
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.
> >
> > T
> > 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 mult
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 cert
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 mpla
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.
>
#include
* 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 this thing
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
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.
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.
>
> Personn
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 pack
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. :)
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 would favor a new files hierachy that allow every
> ar
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
>
> Con
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
"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 m
"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 m
"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 happ
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.
>
>
"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 ker
"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
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
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 requireme
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 s
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 incompatib
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 h
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 t
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 id
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 l
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
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 th
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
dpkg-ar
[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 -- d
"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 version
"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 sa
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
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 b
"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 a
"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
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,
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 fil
[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:
>
"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
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
>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 Archit
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 sa
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 version
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
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 wi
"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, 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
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
arch
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
amd
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 runn
93 matches
Mail list logo
