[EMAIL PROTECTED] (Karl Berry) writes:
> Although I can believe that our own packages could be compiled to avoid
> /usr without an impossible amount of difficulty, this does not take
> account of users' own scripts and programs. Essentially all of which
> depend on /usr, since it has been around
Michael Heath <[EMAIL PROTECTED]> writes:
> The current plan takes a package and makes it's bin/ directory appear
> to be included in /bin, takes the package's usr/ directory and makes
> it appear to be included in /usr, and so on. What he's saying is,
> rather than doing this, you should just hav
Leonardo Pereira <[EMAIL PROTECTED]> writes:
>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
and when the time comes,
I don't think the time will ever come.
I agree completely; we should not suppose that we will
ever eliminate `/usr'.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Hi,
> How about a daemon (or service, or translator, or whatever) that would
> monitor the "/Programs" directory where the new programs are
> installed. And when that daemon sees a new program it automagicaly
> does a "ln -s" for binaries, includes, libraries, etc. That "daemon"
> could be trigger
there is no harm in keeping it around for now,
Glad to hear it. That wasn't clear to me.
and when the time comes,
I don't think the time will ever come.
Although I can believe that our own packages could be compiled to avoid
/usr without an impossible amount of difficulty, this does
find / -P -name FOO
What does -P do? I don't see it in the documentation of find
on my machine.
>From (find)Symbolic Links:
`-P'
`find' does not dereference symbolic links at all. This is the
default behaviour. This option must be specified before any of the
file n
I admit I'm not sure of all the context here, but is there some
proposal that /usr will not resolve in GNU? That seems impractical
to me. Virtually everything ever written uses /usr, one way or
another.
There aren't many things that need /usr, most things will figure out
such informa
I do not think that keep a loop symlink of USR->/ is a good idea,
I admit I'm not sure of all the context here, but is there some proposal
that /usr will not resolve in GNU? That seems impractical to me.
Virtually everything ever written uses /usr, one way or another.
___
Doesn't find know enough not to follow symlinks to directories?
Indeed, by default, it does not follow symlinks to directories.
I would think it ought to.
find / -P -name FOO
What does -P do? I don't see it in the documentation of find
on my machine.
It's in the info m
I do not think that keep a loop symlink of USR->/ is a good idea,
since you will never be able to do a "find / -name
*something*". So, we need to correct those scripts. (* There are
scripts with references to /usr/python or /usr/local/perl)
Doesn't find know enough not
What he's saying is,
rather than doing this, you should just have a utility that keeps the
PATH environment variable updated (by adding hte packages' bin/ and
sbin/ directories), updates ld.so.conf, and so on.
This would be a big step backward. It would result in gigantic PATH
val
when you build a program to work on an directory, all that you will need
from that package is the binary location.
I do not understand any of that. I think you need to give labels
to the various entities that you are talking about, and describe their
relationships clearly.
What you
Hi.
On 2/5/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> StowFS doesn't create links, it uses unionfs. The difference of both is
> almost simple, since with links you can remove stow and everything will keep
> working. With StowFS you need to have stowfs running to get things working
> (this "
StowFS doesn't create links, it uses unionfs.
And unionfs creates virtual symbolic links that don't really exist.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
StowFS doesn't create links, it uses unionfs. The difference of both is
almost simple, since with links you can remove stow and everything will
keep working. With StowFS you need to have stowfs running to get things
working (this "curiously" create a bootstrap problem2006/2/5, Alfred M. Szmidt <[EM
How about a daemon (or service, or translator, or whatever) that
would monitor the "/Programs" directory where the new programs are
installed. And when that daemon sees a new program it automagicaly
does a "ln -s" for binaries, includes, libraries, etc.
That is exactly what stowfs does
Hi,
On 2/5/06, Filip Brcic <[EMAIL PROTECTED]> wrote:
> How about a daemon (or service, or translator, or whatever) that would monitor
> the "/Programs" directory where the new programs are installed. And when that
> daemon sees a new program it automagicaly does a "ln -s" for binaries,
> includes
Дана Sunday 05 February 2006 18:35, Richard M. Stallman је написао(ла):
> What he's saying is,
> rather than doing this, you should just have a utility that keeps the
> PATH environment variable updated (by adding hte packages' bin/ and
> sbin/ directories), updates ld.so.conf, and
Дана Friday 03 February 2006 13:15, Alfred M. Szmidt је написао(ла):
>I do not know what are your problems with my idea. There are some
>Linux-based GNU systems that uses that directory organization.
>
> Sorry, but I know of no GNU/Linux systems that use this. All of them
> are built up ar
The current plan takes a package and makes it's bin/ directory appear
to be included in /bin, takes the package's usr/ directory and makes
it appear to be included in /usr, and so on. What he's saying is,
rather than doing this, you should just have a utility that keeps the
PATH environment variabl
Hi,
On 2/3/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote:
> Possibilities to make a stowfsed system booting:
I was referring to *your* nowstowfs booting stuff, not mine.
As already said previously on this thread, stowfs is implemented as a
set of unionfs running, so no stowfs.static thing may h
I know that there are A LOT of scripts that will need to be
CORRECTED.
Not as many as you think. Most scripts figure out where the
interpeter is at compile/configure time.
I do not think that keep a loop symlink of USR->/ is a good idea,
since you will never be able to do a "find / -
On Fri, Feb 03, 2006 at 02:29:41AM +0100, Alfred M. Szmidt wrote:
> Thing is that they are broken, figuring out where the interpeter is
> should always be done at compile/configure time. Having perl in
> /usr/local/bin is very common for example, and simply hardcoding it to
> /usr/bin will make th
So you basically want a server -- it's not a translator --
receiving notifies of the /packages directory changes and reacting
to dir_notify by changing the PATH environment variable of ALL
processes. I am not an Hurd expert. How do you exactly plan to do
it?
I cannot either see how
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 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.
__
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
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
38 matches
Mail list logo
