there unless we start small and document things piece by
piece. I'm still leaning towards thinking just dropping this section is
better than doing a direct translation of it to the current systemd
reality which might just end up being confusing and help noone.)
Regards,
Andreas Henriksson
RGROUP="_foobar"
if ! getent passwd "$NEWUSERGROUP" && ! getent group "$NEWUSERGROUP"
>/dev/null>/dev/null; then
adduser --force-badname \
--system --group \
--home /nonexistent --no-create-home \
"$NEWUSERGROUP"
fi
--
Regards,
Andreas Henriksson
s the packaging system and the
>
> --
> Sean Whitton
Regards,
Andreas Henriksson
On Sun, Jul 22, 2018 at 11:35:48AM +0800, Sean Whitton wrote:
> control: tag -1 +patch
>
> Hello all,
[...]
Thanks for working on this and thanks for including your rationale
about the tradeoffs you had to make.
While I still retain my aging view on this which isn't perfectly
described by your p
Hello Sean,
On Wed, Dec 27, 2017 at 12:05:15PM +, Sean Whitton wrote:
[...]
> Andreas, Russ -- please considering seconding this updated text.
[...]
Seconded.
Regards,
Andreas Henriksson
leads to
> inconsistent and confusing behavior: ``service start`` may
> return success but not start the service, services with a dependency
> on this service will be started even though the service isn't running,
> and init system status commands may incorrectly claim that the service
> was started.
Seconded.
Regards,
Andreas Henriksson
ould
>prevent the local system administrator from enabling the service with
>a simple `update-rc.d package enable`, which is the whole point of
>all this.
>
>I looked at dh_installinit(8) and update-rc.d(8) and I couldn't get
>them to generate a postinst that does what I want. It seems you're
>expected to use all three of these:
>
>dh_systemd_enable --no-enable
>dh_systemd_start --no-start
>dh_installinit --no-start
>
>but then after a reboot, a sysvinit system will start the daemon,
>AFAICT.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709384
Regards,
Andreas Henriksson
ctises. I think another (or several) bug reports should
be opened if you really intend to undertake documenting (debians
interactions with) systemd.
Thanks alot for your work on policy! Happy to see things moving
forward and Russ getting some well deserved help!
Regards,
Andreas Henriksson
ng them short and to the point previously so I trust you'll
do an excellent job here as well, but if you want help with suggestions
please mention it and a non-native speaker like myself would make an
attempt.
Regards,
Andreas Henriksson
On Sun, Jun 25, 2017 at 03:54:00PM -0700, Russ Allbery wrote
-linux.html
Even if ftp-masters where really keen on actively managing the
overrides file I wonder what purpose this would serve?
As already mentioned previously in this bug backlog it would just be a
waste of ftp-master time.
Either way, I'm adding ftpmaster to CC now.
Regards,
Andreas Henriksson
ould suggest just
removing the harmful parts as an intermediate step.
Is there anything left to resolve before actually editing policy that
I might look into helping out with?
Regards,
Andreas Henriksson
ust second the spirit of the change and not be picky about the exact
wording.)
Regards,
Andreas Henriksson
y the DPLs responsibility to
appoint/delegate editors I'm CCing leader to see if he has any ideas
about how we can recruit and if needed get new editors delegated
(or other ideas about how we can make the policy editor changes flow
smoother. I'm sure he'll be happy to sponsor a sprint if needed).
Regards,
Andreas Henriksson
than mknod to create named pipes so that
> - automated checks for packages incorrectly creating device
> - files with mknod won't have false positives.
> -and removed in
> - the prerm or postrm script as
> - appropriate.
> + than mknod to create named pipes to avoid false
> + positives from automated checks for packages incorrectly
> + creating device files.
> +
> + and removed in either the prerm or
> + the postrm maintainer script.
>
>
>
> --
> 2.11.0
>
(Seems my previous reply dissapeared, so again...)
Seconded.
Regards,
Andreas Henriksson
Hello Russ Allbery,
On Mon, Feb 20, 2017 at 02:42:59PM -0800, Russ Allbery wrote:
> Control: tag 181123 pending
>
> Andreas Henriksson writes:
>
> > These patches is an attempt to finally put #181123 to rest.
>
> > It tries to strike a well balanced middle ground
Package: debian-policy
Version: 3.9.8.0
Severity: normal
Dear Maintainer,
Please consider changing the language in chapter 9.3.3
"Interfacing with the initscript system" from "should" to "must".
Interpretting it as a strict requirement has been the way I've
understood most people to look at it fo
from then the *-rc.d tools where first
introduced.)
Regards,
Andreas Henriksson
Hello Russ,
On Tue, Jan 24, 2017 at 09:29:07AM -0800, Russ Allbery wrote:
> Andreas Henriksson writes:
[...]
> > https://bugs.debian.org/568374
>
> I'm going to try to dig through this. Unfortunately, multiple patches on
> the same bug, some with revisions, some of which
g suggestion with multiple
seconds.
(Please note that this noise is only directed at the list and not the
actual bug report to avoid recording noise.)
Please direct any followups to the actual bug report!
https://bugs.debian.org/568374
Regards,
Andreas Henriksson
be an issue opened where
new wording can be discussed.
Hopeing to see some progress made here soon. Please tell me if there's
anything more I can do to help move this issue forward.
Regards,
Andreas Henriksson
t; initscripts" to the appropriate place in the upgrading checklist.
I agree that the /run transition wording has now served it's
purpose and can be removed to avoid causing confusion, so:
Seconded.
Regards,
Andreas Henriksson
PS. usertag for tracking getting rid of versioned initscripts de
se note that an initial attempt at syncing debian policy and LSB
including try-restart is already in patches posted on
http://bugs.debian.org/181123
More precisely in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181123#50
Please review, comment, object, second.
More work might be needed, the above is just a start.
Regards,
Andreas Henriksson
ndors to
collaborate on the same source in Debian rather than downstreams
carrying their own delta and we stick our head in the sand on the debian
side and pretend it doesn't exist.
Regards,
Andreas Henriksson
dh_installinit is being fixed up to
match, if that somehow helps here or planning for the future.)
Regards,
Andreas Henriksson
say this bug report should simply be closed:
- for the a/ case it's mostly a duplicate of #181123 (and conflict
against the other).
- for the b/ case it seems more like a wonfix bug.
This all seems more like something that could be better described on
a wiki.debian.org page discussing plugin strategies and matching debian
packaging strategies plus links to example packages to look at.
Regards,
Andreas Henriksson
that much of any potential solution to #601455 is also likely not
desirable to have in policy.
Possibly these to bug reports should just be merged (and wontfix tagged
together).
Regards,
Andreas Henriksson
ix at the root of the problem rather than just hide
by following outdated practises in every package on top).
I'm thus happy this bug report has gotten its severity raised recently.
Regards,
Andreas Henriksson
In LSB the status action is among the 'shall be supported' actions.
In Debian there are still many init scripts which does not support
the status action still to this day (see lintian catches for
init.d-script-does-not-implement-optional-option status).
Given we avoid creating a big number of RC b
entire chapter still needs a major overhaul given the world no
longer only revolves around (sysv)init scripts. That's no reason not to
start with this small first step though....
Andreas Henriksson (2):
Document optional try-restart init script action
Document status init script a
Add the try-restart action similar to how LSB describes it.
Many init scripts in Debian still does not support this action
but fortunately even LSB just documents it as optional.
Fwiw, systemctl also supports try-restart action in the same fashion.
---
policy.sgml | 6 +-
1 file changed, 5 in
which are currently handled inconsistently,
> and it would use the familiar name "NEWS" for that file, consistent with
> GNU-type packages and the name NEWS.Debian.
As a final word, I think my interpretation of ChangeLog as changelog and
NEWS as NEWS maps nicely onto how we ha
Hello Henrique de Moraes Holschuh,
Thanks for looking into this!
On Fri, Dec 23, 2016 at 11:56:36AM -0200, Henrique de Moraes Holschuh wrote:
>
>
> On Sat, Dec 17, 2016, at 10:57, Andreas Henriksson wrote:
> > The entire section is specific to sysvinit and already solved
>
In addition to the sysvinit skeleton file also point out
where to find systemd integration examples.
---
policy.sgml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/policy.sgml b/policy.sgml
index 707b716..871011f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7786,6 +7786,8 @@ test -f progr
No idea how long ago this paragraph had any relevance
---
policy.sgml | 13 -
1 file changed, 13 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 2589fe5..707b716 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7780,19 +7780,6 @@ test -f program-executed-later-in-script ||
For several releases the *-rc.d policy tools have always been available
on the system. At points we've had bugs that created corner-cases
which make the *-rc.d tools go missing during an upgrade phase,
but that should not be worked around in each and every package.
Thus remove the check if invoke-r
Todays init systems calculates a dependency graph (eg. from the
dependencies specified in LSB headers) and doesn't go by sequence
numbers. See eg. insserv.
---
policy.sgml | 9 -
1 file changed, 9 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 32e1efc..d1108be 100644
--- a/poli
The intention is to also make sure that eg. it's equally not
allowed to directly call 'systemctl ' but maybe
the wording can be improved further to more clearly express this.
In other words the language is still a bit outdated in this paragraph.
---
policy.sgml | 4 ++--
1 file changed, 2 inserti
It might not be the policy's place to define how the maintainer should
automate the packaging work, but at least mention debhelper to not
fool people into thinking manually writing maintainer scripts is
the preferred method of using update-rc.d.
---
policy.sgml | 8
1 file changed, 8 inse
The entire section is specific to sysvinit and already solved
by LSB in that case. There's no point in reinventing LSB.
Also other init systems handles this in ways that's not at all
described here. Just drop the entire section as it gives no
practical useful information.
---
policy.sgml | 196 ---
These days the information in the LSB header is used.
Manually specifying/overriding runlevels as a parameter to
update-rc.d on command line is even deprecated and a noop stub
these days.
---
policy.sgml | 13 -
1 file changed, 13 deletions(-)
diff --git a/policy.sgml b/policy.sgml
i
It might not be the policys place to define how the maintainer should
automate the packaging work, but atleast mention debhelper to not
fool people into thinking manually writing maintainer scripts is
the preferred method of using invoke-rc.d.
(This is similar to previous commit about update-rc.d
Get rid of "script" as that doesn't properly describe the equivalent for
systems using declarative replacements.
Also drop "the" as via update-rc.d you're potentially/likely interfacing
with multiple ones at a time. Possibly the word system should be
replaced with systems or system(s)?
---
policy
The paragraph ends with
"...until the stable release of Debian supports /run."
which current releases does, so this paragraph is obsolete.
---
policy.sgml | 6 --
1 file changed, 6 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 9cd182b..81df4a3 100644
--- a/policy.sgml
+++ b/policy
t the below one
(Please feel free to make sure I didn't misinterpret or screw
something up while doing so.)
On Mon, Dec 12, 2016 at 03:40:36PM +0100, Martin Pitt wrote:
> Hello Andreas,
[...]
> Andreas Henriksson [2016-12-06 15:07 +0100]:
> > [Replace init example
skeleton
> was problematic too.
The resolution is a bit unfortunate, but oh well :/
> It still generates a default.ex though, which mentions the initscript,
> I'll file a bug about that.
Great. (That file can go even if the init script template comes back IMO.)
Regards,
Andreas Henriksson
Hello Andrey Rahmatullin.
Thanks for your input. (Did you also look at the other patches in the
series? Any objections or support for any of them?)
On Tue, Dec 06, 2016 at 07:21:00PM +0500, Andrey Rahmatullin wrote:
> On Tue, Dec 06, 2016 at 03:07:21PM +0100, Andreas Henriksson wrote:
>
Since several releases the *-rc.d policy tools are always available
on their system. At points we've had bugs that created corner-cases
which make the *-rc.d tools go missing during an upgrade phase,
but that should not be worked around in each and every package.
Thus remove the check if invoke-rc.
The entire section is specific to sysvinit and already solved
by LSB in that case. There's no point in reinventing LSB.
Also other init systems handles this in ways that's not at all
described here. Just drop the entire section as it gives no
practical useful information.
---
policy.sgml | 196 ---
It might not be the policys place to define how the maintainer should
automate the packaging work, but atleast mention debhelper to not
fool people into thinking manually writing maintainer scripts is
the preferred method of using invoke-rc.d.
(This is similar to previous commit about update-rc.d
The dh_make program should generate the current best practises
version and for any current init system. In other word this
wording is more init agnostic (and thus hopefully future-proof).
---
policy.sgml | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/policy.sgml b/policy.
No idea how long ago this paragraph had any relevance
---
policy.sgml | 13 -
1 file changed, 13 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 59cd582..f28060b 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7780,19 +7780,6 @@ test -f program-executed-later-in-script ||
The intention is to also make sure that eg. it's equally not
allowed to directly call 'systemctl ' but maybe
the wording can be improved further to more clearly express this.
In other words the language is still a bit outdated in this paragraph.
---
policy.sgml | 4 ++--
1 file changed, 2 inserti
Get rid of "script" as that doesn't properly describe the equivalent for
systems using declarative replacements.
Also drop "the" as via update-rc.d you're potentially/likely interfacing
with multiple ones at a time. Possibly the word system should be
replaced with systems or system(s)?
---
policy
These days the information in the LSB header is used.
Manually specifying/overriding runlevels as a parameter to
update-rc.d on command line is even deprecated and a noop stub
these days.
---
policy.sgml | 13 -
1 file changed, 13 deletions(-)
diff --git a/policy.sgml b/policy.sgml
i
It might not be the policys place to define how the maintainer should
automate the packaging work, but atleast mention debhelper to not
fool people into thinking manually writing maintainer scripts is
the preferred method of using update-rc.d.
---
policy.sgml | 8
1 file changed, 8 insert
Todays init systems calculates a dependency graph (eg. from the
dependencies specified in LSB headers) and doesn't go by sequence
numbers. See eg. insserv.
---
policy.sgml | 9 -
1 file changed, 9 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 820be8b..af2d1d2 100644
--- a/poli
0 but also takes care of
#833177 as well as wanders into getting rid of section 9.4.
Personally I think #833177 is an example where the part of policy
is actively harmful to follow and would recommend to atleast
apply the commit solving that called:
"Drop legacy code from invoke-rc.d example&
The paragraph ends with
"...until the stable release of Debian supports /run."
which current releases does, so this paragraph is obsolete.
---
policy.sgml | 6 --
1 file changed, 6 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 9cd182b..81df4a3 100644
--- a/policy.sgml
+++ b/policy
date-rc.d policy layer via /etc/default.
(TTBOMK this anti-pattern surfaced because of noone volunteering to fix
dh_installinit to avoid starting/enabling on install, but that has since
long been fixed now.)
Regards,
Andreas Henriksson
mlink must be managed in such a way that it will not
> break when, for example, /bin and /usr/bin
> are the same directory.
>
> Ansgar
>
(Maybe it's nice and helpful to include a hint about handling it in
maintainer scripts but at the same time I wonder if the policy docum
reassign 769273 debian-policy
forcemerge 758234 769273
affects 758234 bsdutils
thanks
Merging one instance of the bug with the more general bug report.
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe"
y can decide if this is a wontfix/jessie-ignore,
if policy editors must update the policy before the jessie release or
if systemd maintainers needs to adjust their priority.
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of
62 matches
Mail list logo
