Remco Blaakmeer wrote:
> > For example, by using reload in the postinst, the downtime of services can
> > probably be minimized at an upgrade (instead using stop in the prerm and
> > start in the postinst).
>
> s/reload in the postinst/restart in the postinst/
>
> 1. 'reload' is not a mandatory o
Here's what's been happening on debian-policy this week.
Please let me know if you think any proposals have a consensus.
Note: for details of the policy process, see
http://www.debian.org/~srivasta/policy/ch3.html. Also, this summary is
available on the web at http://kitenet.net/~joey/policy-week
Julian Gilbey wrote:
> > The technical committee has been asked to resolve the issue of what to do
> > with /usr/share/doc. I propose we actually adopt their decision. I
> > propose further that we don't bother to have discussion--we're past all
> > that. The decision has been made and while pos
On Fri, Sep 24, 1999 at 11:13:27AM -0400, Scott K. Ellis wrote:
> Okay, then solve the problem of which one should actually work on the
> standard port? You can't use update-alternatives if the software is
> launched in a different manner. If you have such an advanced setup, it
> isn't really tha
On Fri, Sep 24, 1999 at 11:34:28PM -0500, The Doctor What wrote:
> I do not like the idea of a daemon starting up with a default
> configuration that I have not double checked upon installation. I
> consider automatically starting with no choice a misfeature.
I think I agree.
I got a rude start
The Doctor What wrote:
> Why shouldn't *all* daemon packages ask these questions, and whether to even
> run *upon install*?
Because we need to decrease the number of questions asked at install time,
not increase it.
--
see shy jo
On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote:
> The Doctor What wrote:
> > Why shouldn't *all* daemon packages ask these questions, and whether to even
> > run *upon install*?
>
> Because we need to decrease the number of questions asked at install time,
> not increase it.
How about
On Mon, 20 Sep 1999, Joseph Carter wrote:
> The technical committee has been asked to resolve the issue of what
> to do with /usr/share/doc. I propose we actually adopt their
> decision.
I second this.
> I propose further that we don't bother to have discussion--we're
> past all that.
And I se
Seth R Arnold wrote:
> How about add one question: "Automatically start all daemons: [Y/n]"
>
> If they answer yes, then no questions. If they answer no, ask as many
> questions as you want. :)
>
> Of course, the downside of this particular question is ... not *all* daemons
> should be automatica
On Fri, Sep 24, 1999 at 07:38:23PM -0700, Joey Hess wrote:
> I think someone needs to write a policy diff. It can use how debhelper does
> things as the reccomended method, without metioning debhelper. For example:
I second this proposal assuming it is amended with this or equivalent diff.
--
%%
Joey Hess <[EMAIL PROTECTED]> writes:
> This just shows why policy should not specify. This is an area where the
> maintainer should be allowed to use common sense.
>
> If you maintain a package, you _wrote_ the init script. You know if it
> supports reload, and if so, you use it. Otherwise, you
Raul Miller <[EMAIL PROTECTED]> writes:
> Our job is to give them a better alternative.
>
> > The fact that the FHS makes their existence optional, means that it's
> > not insisting that we install them.
>
> True, but this doesn't solve any problems as far as I can see.
The status quo is that t
On Fri, Sep 24, 1999 at 08:24:55AM +0300, Antti-Juhani Kaijanaho wrote:
> > As for the technical implementation of the tech-ctte decision, I propose
> > we use joeyh's implementation found in any recently uploaded debhelper
> > package.
>
> Please clarify this. Preferably give the diff you want t
Joseph Carter wrote:
> On Fri, Sep 24, 1999 at 08:24:55AM +0300, Antti-Juhani Kaijanaho wrote:
> > > As for the technical implementation of the tech-ctte decision, I propose
> > > we use joeyh's implementation found in any recently uploaded debhelper
> > > package.
> >
> > Please clarify this. Pr
> Data section (#38902)
> * Consensus.
> * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S
> Galbraith and Peter Makholm.
> * "Since there is interest in packaging census data, maps, genome
> data and other huge datasets I and since most people agreed that
> dropp
15 matches
Mail list logo
