Bob Hilliard wrote:
> I can not find this documented anywhere, but I have always
> understood that policy was supposed to be the represent a consensus of
> the developer's views after discussion on debian-devel. Once the
> constitution is adopted, I believe the Technical Committee should pass
I can not find this documented anywhere, but I have always
understood that policy was supposed to be the represent a consensus of
the developer's views after discussion on debian-devel. Once the
constitution is adopted, I believe the Technical Committee should pass
on new mandatory policy ite
I think it's important to consider the case of more complicated programs
such as mailers. Obviously as the maintainer of exim I have an interest in
this.
There's no way to automatically generate configuration files that will work
on all systems; the best I can hope for really is 90%. Therefore sto
Andreas Degert <[EMAIL PROTECTED]> wrote:
> If I just install one package, it's ok that a lot of output is
> produced, and maybe some questions are asked. But when I upgrade
> a batch of packages or install a new system, it's not an optimal
> solution.
This doesn't scale to multiple machines.
If
I don't know if this would be possible, but it would be very impressive if
we could (optionally) re-run the appropriate scripts when a value changed.
For instance if "hostname" or "IP-address" changed, we could re-run all the
postinst scripts that needed them.
Probably too difficult and full of p
Hi,
During a discussion on -devel between Joey Schulze, Miquel van
Smoorenburg and myself on the difficulties of adding new shutdown
scripts to /etc/rc0.d, I suggested (slightly jokingly) that debian may
need a policy of number ranges within the startup/shutdown script
sequence managed by update-
This is an issue I have seen discussed in many different settings... in
business, organizations, or anything else that needs policies or laws. The
basic question that needs to be kept in mind and answered is: What is a
policy, and what is it intended to do?
What it's intended to do is the
Hamish Moffatt writes ("Re: Policy as rule of law, or whatever"):
> On Tue, May 19, 1998 at 01:11:31PM +0100, Ian Jackson wrote:
> > 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 definitio
Hi,
wouldn't it be better to not ask any question at all as part of the
core installation process? Sorry, this mail is long, I hope this
hasn't been covered extensively before (please supply pointers).
If I just install one package, it's ok that a lot of output is
produced, and maybe some questio
On Mon, 18 May 1998, Jules Bean wrote:
> --On Mon, May 18, 1998 8:25 pm +0200 "Remco Blaakmeer"
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 13 May 1998, Joey Hess wrote:
> >
> >> Hundreds of packages use menu. The calls to menu are guarded by a test to
> >> see if menu is installed:
> >>
> >> i
On Tue, May 19, 1998 at 01:11:31PM +0100, Ian Jackson wrote:
> 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 docume
Oliver Elphick writes ("Re: Proposal: Automatic query servicing for dpkg
installation scripts "):
...
> Are there any scripts that actually build their questions?
Oh, and look at things like smailconfig.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troubl
Oliver Elphick writes ("Re: Proposal: Automatic query servicing for dpkg
installation scripts "):
...
> Are there any scripts that actually build their questions? Isn't it
> usually (always?) the case that the question is in the script as a text
> string, though the logic may skip it? Where para
(Crosspost to debian-devel removed.)
Raul Miller writes ("Re: Proposal: Automatic query servicing for dpkg
installation scripts"):
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> > 2. Only a particular package can determine which questions need to be
> > asked in what order; in particular, following q
Jason Gunthorpe wrote:
[comments on use of ASN.1 notation for this purpose]
>Some things we should look at,
> - Free ASN.1 parsers/libraries, I think one is around
> - What fields can be borrowed from SNMP and what more do we need?
> - Consider how we would model some of the existing set
On Tue, 19 May 1998, Oliver Elphick wrote:
> Well, having looked at COAS, it seems not to dictate any particular data
> format; it has to cope with a large number of independently developed
> packages, each with its own format. To add a new one means writing a
> module which plugs into COAS to
16 matches
Mail list logo
