Hi,
On 2/3/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> What you will need is, instead stowfs, that get package/bin and merge it on
> /bin, is a translator that gets package/bin and put it on PATH. The same is
> valid for /lib and /sbin (I know no variable to set "include" directories).
So
I wrote the previous email with haste, so I could not explain my idea
completely and, with your doubts about it, I can explain it better.
I know that there are A LOT of scripts that will need to be CORRECTED.
I do not think that keep a loop symlink of USR->/ is a good idea,
since you will never be
> And this is easy to do, provide /usr as a symbolic link to / if
> such support is needed.
Yes, of course. I just meant to say that those programs (scripts)
shouldn't necessarily be considered broken... even if they truly
are.
Thing is that they are broken, figuring out where the
Hi,
(CCing to gnu-system-discuss)
On 2/2/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> I was thinking about why we need to merge all packages on the root
> filesystem is this is not a requirement of POSIX. Posix uses PATH to
> determine where the executable files are, lib directories are sett
> And this is easy to do, provide /usr as a symbolic link to / if
> such support is needed.
Or you could frob bash's she-bang parsing.
Easier to frob exec. Then all shells that do hash-bangs will follow.
Make exec strip the leading directory, and then you have something
like `#!foo', w
Дана Friday 03 February 2006 01:58, Alfred M. Szmidt је написао(ла):
>I do agree that such a behavior could be considered broken, but if
>most of the programs do that I believe that the support for them
>should be provided.
>
> And this is easy to do, provide /usr as a symbolic link to
Дана Thursday 02 February 2006 23:45, Alfred M. Szmidt је написао(ла):
> Fixing hard coded filenames is easy. One can always provide a /usr
> symbolic link. Infact, any program that depends on a hard coded file
> name is seriously broken.
Most of the shell, perl, python scripts do depend on a ha
On Mon, Oct 31, 2005 at 01:40:57AM +0100, Alfred M. Szmidt wrote:
> The following patch fixes the following problem (reported by Sergio):
>
> | I'm having trouble with the GNU Mach of your tarball, it stalls with
> | "panic: free_irq: bad irq number" just after the floppy disk
> | detection. I've
On Fri, Feb 03, 2006 at 01:58:54AM +0100, Alfred M. Szmidt wrote:
>I do agree that such a behavior could be considered broken, but if
>most of the programs do that I believe that the support for them
>should be provided.
>
> And this is easy to do, provide /usr as a symbolic link to /
I do agree that such a behavior could be considered broken, but if
most of the programs do that I believe that the support for them
should be provided.
And this is easy to do, provide /usr as a symbolic link to / if such
support is needed.
Cheers.
__
Hi all,
I am trying to checkout latest /gnumach from
cvs.savannah.gnu.org using the command "cvs -z3
-d:pserver:[EMAIL PROTECTED]:/sources/hurd
co gnumach".
I am getting error "cvs [checkout aborted]: could not
chdir to gnumach/i386/aux: Invalid argument"
any ideas?
- Ashish
__
On Thu, Feb 02, 2006 at 09:53:22PM +, Ashish Gokhale wrote:
> I am trying to checkout latest /gnumach from
> cvs.savannah.gnu.org using the command "cvs -z3
> -d:pserver:[EMAIL PROTECTED]:/sources/hurd
> co gnumach".
> I am getting error "cvs [checkout aborted]: could not
> chdir to gnumach/i3
The problem I can see with this is compatability with hardcoded paths.
There is, for example, a lot of scripts out there that have their magic
set to /usr/bin/perl, or /bin/bash; You'd require customization of an a
lot of things if perl or bash were simply on the PATH and not where most
things expe
On Thu, Feb 02, 2006 at 02:49:24PM -0200, [EMAIL PROTECTED] wrote:
> On Thu, Feb 02, 2006 at 11:24:32AM +0100, Marco Gerards wrote:
> > Gianluca Guida <[EMAIL PROTECTED]> writes:
> >
> > >> P.S. Gianluca, it'd probably be a good time now to request and sign
> > >> assignment papers for GNU Mach.
>
Update of bug #15073 (project hurd):
Status: In Progress => Fixed
Assigned to:None => tschwinge
Open/Closed:Open => Closed
On Sun, Jan 29, 2006 at 12:29:02AM -0200, [EMAIL PROTECTED] wrote:
> A fixed patch for supporting passive translators in Linux follows.
I have now built Ubuntu breezy and Debian unstable kernel package (686
flavour only) with that patch.
I only tested the Ubuntu breezy one, but getfattr/setfattr
Fixing hard coded filenames is easy. One can always provide a /usr
symbolic link. Infact, any program that depends on a hard coded file
name is seriously broken.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
I was thinking about why we need to merge all packages on the root
filesystem is this is not a requirement of POSIX. Posix uses PATH
to determine where the executable files are, lib directories are
setted on /etc/ld.so.conf, others directiories of packages are not
important to the sy
I was thinking about why we need to merge all packages on the root
filesystem is this is not a requirement of POSIX. Posix uses PATH to
determine where the executable files are, lib directories are setted on
/etc/ld.so.conf, others directiories of packages are not important to
the system at all, on
On Thu, Feb 02, 2006 at 11:24:32AM +0100, Marco Gerards wrote:
> Gianluca Guida <[EMAIL PROTECTED]> writes:
>
> >> P.S. Gianluca, it'd probably be a good time now to request and sign
> >> assignment papers for GNU Mach.
> >
> > Hmph, I requested that for the Hurd and GNU Mach, but now that I look
Gianluca Guida <[EMAIL PROTECTED]> writes:
>> P.S. Gianluca, it'd probably be a good time now to request and sign
>> assignment papers for GNU Mach.
>
> Hmph, I requested that for the Hurd and GNU Mach, but now that I look
> at it, in the copyright assignment paper I signed one year ago only
> GNU
21 matches
Mail list logo