On Wed, 11 Dec 2002, Bill Allombert wrote:
Here a patch that clarify the behavior of /etc/init.d/foo restart.
This is taken straight out of
LSB 1.2 / Chapter 22. / System Initialization / Init Script Actions
--- policy.sgml 2002-11-15 07:49:40.0 +0100
+++ policy.sgml.new
On Thu, 05 Dec 2002, Michael Lamertz wrote:
Oh dammit, do we really have to enter these dark lands...
Apparently. Let me get my scuba suit, and a harpoon...
On Wed, Dec 04, 2002 at 09:49:17PM -0200, Henrique de Moraes Holschuh wrote:
the module which works perfectly well on, ... well
On Wed, 04 Dec 2002, Michael Lamertz wrote:
Except for core packages, that shouldn't happen, since packages install
Then any proposed solution should take that into account...
Josip Rodin suggested on debian-policy that I should file a bug report
against the package that contains
On Thu, 21 Nov 2002, era eriksson wrote:
--- 5823,5835
p
Any configuration files created or used by your package
must reside in tt/etc/tt. If there are several you
! should create a subdirectory of tt/etc/tt
named after your package./p
I
On Thu, 12 Sep 2002, Oliver Elphick wrote:
On Thu, 2002-09-12 at 18:43, Robert Bihlmeyer wrote:
Starting and stopping a service should be idempotent, i.e. further
attempts should silently succeed.
I don't agree with that, if that is what current policy says (but I
don't think it does).
On Wed, 11 Sep 2002, Bill Allombert wrote:
I feel it is very important every init script behave the same. However the
wording of section 10.3.2 is confusing:
The init.d scripts should ensure that they will behave sensibly if invoked
with start when the service is already running, or
On Tue, 10 Sep 2002, Chris Waters wrote:
~ $ grep update-rc.d /var/lib/dpkg/info/*{pre,post}{inst,rm}|wc -l
88
If you use update-rc.d, you will call init scripts with 99.9% probability.
That means you _will have to_ switch to invoke-rc.d (sooner or later
anyway). For people using
On Sun, 08 Sep 2002, Chris Waters wrote:
First, I'd like to say that I'm fairly neutral in this debate. None
So am I, actually. I am proposing it because I said at debconf2 that I
would, after the people there got convinced it would be a good thing by
whomever proposed it.
1. Since we'll be
As it was talked in Debconf2, we would be better off if we renamed all
*-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-*
(rc.d-invoke, rc.d-policy, rc.d-update).
Transition plan:
1a. Rename all scripts to their new names, add compatibility symlinks to
the sysvinit and
On Mon, 19 Aug 2002, Oliver Elphick wrote:
Are we still supposed to maintain the /usr/share/doc/x - /usr/doc/x
link for uploads to sarge?
No.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the
On Mon, 19 Aug 2002, Joey Hess wrote:
Of course policy still says we must. I don't know when we want to change
that; now or when a lot of packages have stopped including it, or what.
Well, if we simply change policy not to say anything, then including it is
not against policy.
Later we forbid
On Sun, 18 Aug 2002, Richard Braakman wrote:
This would lose a feature that I find valuable: usually, recompiling
a package with the debug option will generate a binary whose symbols
are compatible with the normal packaged binary. I have used this
several times to chase down hard-to-find
On Mon, 22 Jul 2002, Joey Hess wrote:
So can we get something in policy about invoke-rc.d now? I'm chomping at
Yes, please apply the already approved stuff. policy has been unfrozen,
now...
I will send to this list before tomorrow a new prolicy proposal to account
for the transition from
On Sun, 14 Jul 2002, Bernd Eckenfels wrote:
After short discussion on debian-devel it is obvious, that the section on
policy about the restart and force reload of daemons in init.d scripts could
I agree with that. We do not define what force-reload does if the service
is not running [and it
On Wed, 12 Jun 2002, Wichert Akkerman wrote:
Previously Branden Robinson wrote:
2) The examples advise people to redirect the output of update-rc.d to
/dev/null. Adam Heath and I feel this is a bad idea, and even if this
change is not made, some people (like the author of lintian; see Bug
On Sat, 01 Jun 2002, Marcus Brinkmann wrote:
Do please notice we have (at least) *TWO* classes of arch identification
strings. What RMS seems to be asking us to do is to change all of them to
have '-gnu'. That is *NOT* what I am talking about.
Actually, RMS is concerned about the
On Wed, 29 May 2002, Matthias Klose wrote:
Ok, now that we separate woody and unstable, it is time to think about
this. IMO, this is not a gcc only thing. So propably it should be
changed in dpkg/policy first. debian-cpu-linux-gnu and
cpu-linux-gnu come to mind as an alternative.
Ben
On Fri, 08 Feb 2002, Joey Hess wrote:
Henrique de Moraes Holschuh wrote:
Please document this, it may save someone a grave bug someday, and maybe
even avoid a lot of headaches.
Does it really need to be documented in policy? debconf-devel(8)
Well, one need not document that in policy
Package: debian-policy
Version: 3.5.6.0
Severity: minor
The debconf specification text says:
The config-file contains a new element, which I call the configmodule.
This is a program that will determine the configuration before the package
is unpacked. This means it is run before the
On Wed, 16 May 2001, Joey Hess wrote:
--- policy.sgml.orig Tue May 15 21:57:25 2001
+++ policy.sgml Tue May 15 22:14:28 2001
@@ -1024,6 +1024,38 @@
/p
/sect1
+sect1
+ headingTasks/heading
+
+ p
+ The Debian install process allows the
I second this proposal, in the form taken on the message with the msgid
[EMAIL PROTECTED]
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux godzillah.rivendell.sol 2.2.19 #1 Thu Mar 29 19:31:38 BRT 2001
i586
Versions of packages debian-policy depends on:
ii
On Fri, 11 May 2001, Anthony Towns wrote:
--- policy.sgml Sun Apr 29 05:10:09 2001
+++ policy.sgml.std Fri May 11 11:10:09 2001
@@ -1186,9 +1186,9 @@
p
In the source package's ttStandards-Version/tt control
- field, you must specify the most recent
On Sun, 06 May 2001, Anthony Towns wrote:
So, here's the deal. We need to get a proper policy for tasks fairly soon.
I agree. The current task-* packages are mostly useless cruft for what they
were supposed to do, i.e. help users during the install.
* There should only be a limited
101 - 123 of 123 matches
Mail list logo
