Miquel van Smoorenburg wrote:
> sh script.sh is very different from running it in a subshell with ().
> For example, bash doesn't really fork a new invocation - it just
> sets up a new internal environment temporarily. It's a speed optimization.
I didn't learn this. However it's funny that even s
Ian Jackson wrote:
>Biased summary:
>
>My scheme:
> * keep the user's filesystem consistently laid out during transition.
For what value of "consistent"? If the search path for man pages includes
both /usr/man and /usr/share/man, why should it be inconsistent to have
man pages in both? We alread
Le Wed, Oct 21, 1998 at 01:44:43PM +0100, Ian Jackson écrivait:
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
Yes, my first mail had no sense if we consider it that way... let me
explain a bit
Previously Ian Jackson wrote:
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
Indeed. The design even has a way of preconfiguring systems:
you can put configuration in a remote database and tell
Raphael Hertzog writes ("Configuration management goal"):
...
> I think we have jumped over a step : the configuration is managed in the
> postinst script. But most package does not clearly separate
> post-installation from configuration. And this difference should really
> exist. If I want to ins
According to Martin Schulze:
> Miquel van Smoorenburg wrote:
> > In article <[EMAIL PROTECTED]>,
> > Martin Schulze <[EMAIL PROTECTED]> wrote:
> > >So regular *.sh scripts must not contain any "exit" statement.
> > >(which is the case e.g. for keymap.sh)
> >
> > Ah, now I remember. This has been
Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Martin Schulze <[EMAIL PROTECTED]> wrote:
> >So regular *.sh scripts must not contain any "exit" statement.
> >(which is the case e.g. for keymap.sh)
>
> Ah, now I remember. This has been solved quite some time ago.
> *.sh scripts
In article <[EMAIL PROTECTED]>,
Martin Schulze <[EMAIL PROTECTED]> wrote:
>So regular *.sh scripts must not contain any "exit" statement.
>(which is the case e.g. for keymap.sh)
Ah, now I remember. This has been solved quite some time ago.
*.sh scripts may contain an "exit" statement, because th
Ian Jackson wrote:
> > Interesting point, yes. However, I think we need to fix the source
> > skew problem now, and it's relatively easy: fix dinstall not to delete
> > sources, and run a cron job occasionally to delete obsolete ones.
Richard Braakman <[EMAIL PROTECTED]> wrote:
> It is not quite
Miquel van Smoorenburg wrote:
> > >b) All scripts in /etc/init.d, /etc/rc.boot and similar directories
> > > have to be standalone shell scripts. They must have the 'x' flag
> > > turned on and contain a regular command to execute them in the
> > > first line (such as "#! /bin/sh"). The
In article <[EMAIL PROTECTED]>,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> *This is opinion*.
Okay ;)
> I would not have expected the init.d scripts to be generally
> sourced by rc, and woud be surprised not to have them regular
> standalone scripts (I often call them manually, a
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Are we sure that a flat directory structure is good enough? I
> have tons and tones of icons gathered over the years, and I have to
> use the following directory structures. I find dividing the top level
> into types - background, 16x16, 32x32
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I agree, as well, but only for the root acoount. I have
> provided additional explanation in another message.
Yes, it doesn't make much sense for user accounts, which are not set up
in the base system. So should some text be included in policy
It'd like to add this:
These scripts should not depend on having correct settings in the PATH
variable.
It's been just over a week since I proposed this, and although I got
consensus from those people as maintain window managers before
proposing it, I only got one second here so far. Is my proposal
really that bad?
To recap my proposal briefly: (read the full text at the bottom of
http://www.debian
Ian Jackson <[EMAIL PROTECTED]> writes:
> As far as I'm concerned this leaves undecided only the following
> question: how can we best organise this and what should the result
> look like ? So far we have seen two proposals:
> i. Simply have them side by side, with some kind of way of making
>
16 matches
Mail list logo
