Ian Jackson wrote:
>Yes, we do need something like this.
>
>Properties that it needs to have include (and not all of these are
>true of your proposal), in no particular order:
>
>1. Questions may need to be `independent' of any particular package.
>
>2. Only a particular package can
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Umm, I am not entirely sure I follow. The ``but'' seems to
> imply you object to the statement; however, there may be o
> ``grandfather'' packages installed; either becuse this is a new
> install, or because the user had chosen not to install a
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Ian Jackson <[EMAIL PROTECTED]> wrote:
>> 2. Only a particular package can determine which questions need to be
>> asked in what order; in particular, following questions can depend on
>> the previous ones. This means that we can't
Sounds resonable and that is how I have seen many developers do it.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ian Jackson <[EMAIL PROTECTED]> wrote:
> 2. Only a particular package can determine which questions need to be
> asked in what order; in particular, following questions can depend on
> the previous ones. This means that we can't specify the questions in
> advance in a file. Instead, we have to pu
Yes, we do need something like this.
Properties that it needs to have include (and not all of these are
true of your proposal), in no particular order:
1. Questions may need to be `independent' of any particular package.
2. Only a particular package can determine which questions need to be
asked
Guy Maor writes ("Re: Purging database packages"):
> "Oliver Elphick" writes:
> > I interpreted the sentence `No attempt is made to unwind after errors during
> > removal.' to mean that exit status is not checked. Is that the case?
>
> ? I wouldn't have thought that was the case, but now am not
I think my main problem with the `pro-strong-policy' arguments that
I've been seeing here is that they seem to imply an assumption that
policy is by definition correct, and that any point where it wasn't
the relevant policy document maintainer would agree at once.
How about the following: we defin
Jason Gunthorpe wrote:
>
>On Tue, 19 May 1998, Oliver Elphick wrote:
>
>> I'm sure there are a lot of problems I haven't thought of; if the whole
>> thing is impractical, tell me now! On the other hand, if it can be fully
>> worked out, all packages should use it to do interactive quer
On Mon, May 18, 1998 at 02:04:08PM +0300, Tommi Virtanen wrote:
> On Sun, May 17, 1998 at 03:52:58PM -0600, Anthony Fok wrote:
> > However, I would like to amend the above. (BTW, is it a Policy? I
> > couldn't find the word "frozen" in the Policy Manual. ;-) IMHO, the above
> > rule should not
> >I thought it only implied one bit of configuration information somewhere
> >under /etc/.
Oliver Elphick wrote:
> Yes, but this is a particular case of the general problem of interactive
> installation scripts. Furthermore, this particular case is one that is a
> bit extreme: on installin
Jason Gunthorpe wrote:
...
>If COAS is truely what it claims the implementing a program to pull
>information from the database for use in a script should be fairly
>simple..
OK, I'm having a look at it...
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight
Raul Miller wrote:
>> >I would like to see a way to preemptively indicate that the
>> >data should not be deleted. In a busy environment with several
>> >sysadmins, you want to be able to make such decisions ahead of
>> >time.
>
>Oliver Elphick wrote:
>> This seems a good ide
Oliver Elphick wrote:
> >> 3. Should there be policy on this matter for database packages in
> >> particular?
Raul Miller wrote:
> >I would like to see a way to preemptively indicate that the
> >data should not be deleted. In a busy environment with several
> >sysadmins, you want to be abl
On Tue, 19 May 1998, Oliver Elphick wrote:
> I'm sure there are a lot of problems I haven't thought of; if the whole
> thing is impractical, tell me now! On the other hand, if it can be fully
> worked out, all packages should use it to do interactive queries on
> installation.
Just off hand, I
This is a proposal for a package which can be used by Debian maintainers
to allow interactive queries in their installation scripts to be answered
non-interactively, or to record interactive responses.
This would have to be an essential package and installed with the base
system.
The package woul
Raul Miller wrote:
>Oliver Elphick wrote:
>> 3. Should there be policy on this matter for database packages in particul
>ar?
>
>I would like to see a way to preemptively indicate that the data
>should not be deleted. In a busy environment with several sysadmins,
>you want to be
17 matches
Mail list logo
