On Sun, Nov 21, 1999 at 12:41:42AM +0100, Marcus Brinkmann wrote:
Please note that Debians architecture and ftp set up make it difficult at
least to say:
This package is for all linux systems.
This package is for all linux systems, but needs to be recompiled on each.
This package is for
* Jason Gunthorpe (Sat, Nov 20, 1999 at 11:16:41PM -0700)
I would be inclined to say that any attempt to port Debian to
*BSD or otherwise should include glibc - it would not longer
*BE* Debian unless it included glibc and the rest of our
standard packages. (IMHO)
What, then, does it take to
On Sun, Nov 21, 1999 at 12:35:11AM -0500, Raul Miller wrote:
(1) FreeBSD's support for running linux binaries needs to be enhanced.
If done, that reduces the scope of the problem. If not done the problem
is rather nasty. [I understand that dpkg and bash have problems running
under this
On Sun, Nov 21, 1999 at 12:33:35PM +1100, Hamish Moffatt wrote:
On Fri, Nov 19, 1999 at 10:38:50PM -0800, Joey Hess wrote:
Clint Adams wrote:
Why would you use an emulated binary when you can
easily have a native one?
Who said anything about emulated binaries? Port glibc to freebsd,
On Sun, Nov 21, 1999 at 02:41:13PM +0100, Marcus Brinkmann wrote:
syscalls are a different issue. Software using syscalls can be declared
as such, and only installed on systems that provide such syscalls or an
emulation.
Well, that's true. But syscall itself is just a libc function.
Also,
While there's nothing inherently wrong with rebuilding the world, in the
current circumstances it seems more like a competitive strategy than an
enhancement strategy.
Sure. Let's get functional i386-emulation for sparc, m68k, and
alpha, and then we can save a whole lot of archive bloat and
On Sun, Nov 21, 1999 at 12:33:27PM -0500, Clint Adams wrote:
Sure. Let's get functional i386-emulation for sparc, m68k, and
alpha, and then we can save a whole lot of archive bloat and they
can save the trouble of porting and rebuilding everything.
I guess you just can't see how this is
On Sun, Nov 21, 1999 at 01:25:26PM +0100, Stig Sandbeck Mathisen wrote:
What, then, does it take to _be_ debian? Is it the people? The
policy? The debian-administration and package-bulding packages?
Are these less important than any single package?
Depends on context.
Certainly, the
I guess you just can't see how this is different from the case where
you have two different kernels for the same cpu, and they already have
the capability of running many of the same binaries?
They can? I thought iBCS was dead.
Or did you have a point?
Why would emulation under a different
Hi,
On Sun, Nov 21, 1999 at 09:05:29AM -0500, Raul Miller wrote:
On Sun, Nov 21, 1999 at 02:41:13PM +0100, Marcus Brinkmann wrote:
syscalls are a different issue. Software using syscalls can be declared
as such, and only installed on systems that provide such syscalls or an
emulation.
On Sun, Nov 21, 1999 at 02:01:46PM -0500, Clint Adams wrote:
Why would emulation under a different kernel be any more acceptable
than emulation of a different processor?
Because the first is not emulation in the usual case. Because you don't
emulate a processor. Because you don't provide a
At 12:33 +1100 1999-11-21, Hamish Moffatt wrote:
On Fri, Nov 19, 1999 at 10:38:50PM -0800, Joey Hess wrote:
Who said anything about emulated binaries? Port glibc to freebsd, and use it
natively.
You still need syscall emulation, which is what the BSD linux-compat
stuff does.
No you don't, a
I think the issue is not if we don't want to have any package recompilation.
The issue is if we can take advantage of binary compatibility where it
doesn't make a difference.
By attempting to fill demand for FreeBSD kernel with Debian by
providing a FreeBSD kernel with Linux binary support and
On Sat, Nov 20, 1999 at 08:33:46PM -0800, Joel Klecker wrote:
No you don't, a native FreeBSD port of glibc2 wouldn't have any need of
Linux system call emulation.
So the library maps a standard set of syscalls onto whatever kernel
you're actually using?
(Sorry for the dumb questions; I'm just
14 matches
Mail list logo
