Re: Bug#802501: init script failures during postinst and related scripts

[Daniel Pocock]

On 22/10/15 12:26, Henrique de Moraes Holschuh wrote:
> On Tue, Oct 20, 2015, at 14:08, Daniel Pocock wrote:
>> If postinst or one of the other scripts does a service restart and the
>> restart operation fails, should the postinst abort or should it mask the
>> error, continue and return success?
> 
> Whatever makes more sense for that particular service, as in "safer". 
> And by safer I do mean: smaller chance of aggravating already present
> damage, causing security issues, or data loss".
> 


Ok, I thought about this some more in terms of what should be in the
policy document

It is a situation of minimizing damage: if one of the pre* or post*
scripts fails during a big dist-upgrade, it sometimes leaves the system
in a very bad state.  Being able to "apt-get dist-upgrade" the same box
every 2 years is one of the beautiful things about Debian that people
respect.

So, I feel that by default, if errors occur when trying to stop or start
services, the policy should encourage people to write the scripts in
such a way that they continue anyway.  If somebody really cares about
whether a particular daemon is running at the end of their upgrade, they
should be monitoring it with Nagios or some other tool.  These scripts
are primarily responsible for ensuring that the files on the system are
in a consistent state.

That is the default attitude people should take, but with exceptions:

- stopping daemons: if the maintainer scripts have to make some changes
to data (e.g. changing a schema), they should not attempt to do so if
the attempt to stop the daemon fails.  In this case, the daemon should
be stopped in the preinst of the new version of the package.  If the
preinst script can't stop the daemon it should abort.



>> If it continues, is there any other convention for reporting the
>> problem, e.g. stderr?
> 
> You report errors and warnings to stderr, yes.  For sysvinit there is a
> shell API that can be used for that.  Systemd might have its own
> convention for unit files.
> 
> A better way to get error/warning information to the user would be
> welcome, but it needs to be properly planned (headless nodes, unattended
> upgrades, desktops with crippled local mail delivery/routing, etc).
> 


Thanks, I'm aware of the way the init scripts should use log_warning_msg
and friends.  I was only asking about any specific logging or reporting
that the pre* and post* scripts should do, maybe that should also be
mentioned in this section of the policy and included in the example.

Bug#567033: Clarify status of /usr/games

[Alexandre Detiste]

Hi,

I'd quite _like_ to keep /usr/games separete because it makes it
easy to implement a "you're grounded" scheme along things like
'iptables -A OUTPUT -o eth0 -m owner --uid-owner {CHILD_USERNAME} -j REJECT'
could be use to block web access.

~

I would insist a bit more for /usr/share/games : when commercial
games get installed with game-data-packager, those will
dwarf the other packages, and can fill a "/ + /usr" filesystem
mounted on a cheap 64Gb SSD pretty fast.

Keeping /usr/share/games separate makes it easy to
mount it on a HDD or even via NFS.

$ dpigs 
2063510 freespace2-data
1519641 doom3-data
1303784 feeble-files-orig-es-video
1254020 grimfandango-fr-data
1157177 zork-grand-inquisitor-data
1139350 feeble-files-es-data
1047295 curse-of-monkey-island-fr-data
1015662 toonstruck-fr-data
..
350229 triplea
...
167364 gcompris-data
167298 linux-image-4.1.0-2-amd64 (place 60)

signature.asc
Description: This is a digitally signed message part.

Re: Bug#802501: init script failures during postinst and related scripts

[Sam Hartman]

> "Daniel" == Daniel Pocock  writes:


I agree.
I think Henrique's advice is correct as far as it goes.
However as a distribution, I think we should explicitly encourage people
to consider the consequences on dist-upgrade and other operations.
For some daemons, where the system is likely to be totally broken,
having the installation break is probably the right answer.
If  the postinst is reasonably convinced that the problem is going to
make additional installation difficult (for example root partition or
/usr full) then failing also make sense.

However, for the vast majority of daemons, breaking installation is far
worse than a silent failure to restart.

I believe that this is a significant problem in Debian today andsystemd
makes this  a
significant regression of jessie over wheezy.
(Here I'm not saying systemd is bad; it does a better job of reporting
errors to postinst.; it just gives us behavior that sucks for our users)

--Sam

Re: [developers-reference] [PATCH] Make it easier to update devref for a new Debian release.

[Paul Wise]

On Thu, 2015-10-15 at 23:39 +0800, Paul Wise wrote:

> Make it easier to update devref for a new Debian release.

FYI, I have fixed the build errors, compared the binary packages
before/after the patch using diffoscope and pushed the patch to git.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

[developers-reference] 01/01: Make it easier to update devref for a new Debian release.

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit fc56ee5bbbfe406dc00bf6bf7572b77889bf8056
Author: Paul Wise 
Date:   Thu Oct 15 23:33:52 2015 +0800

Make it easier to update devref for a new Debian release.

Move information about codenames/versions into the entities.

Refer readers to the website for a list of obsolete releases.
---
 common.ent| 13 +
 pkgs.dbk  | 17 -
 resources.dbk | 19 ---
 3 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/common.ent b/common.ent
index ca802a4..a1ec2b0 100644
--- a/common.ent
+++ b/common.ent
@@ -15,6 +15,18 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
 
@@ -67,6 +79,7 @@
 https://db.debian.org/machines.cgi;>
 https://buildd.debian.org/;>
 https://release.debian.org/wanna-build.txt;>
+https:///releases/;>
 https://lists.debian.org/debian-project/2009/03/msg00096.html;>
 https://lintian.debian.org/;>
 https://qa.debian.org/;>
diff --git a/pkgs.dbk b/pkgs.dbk
index 126eaac..d4acfad 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1,5 +1,4 @@
-
- http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [
%commondata;
 ]>
@@ -1124,7 +1123,7 @@ Be sure to verify the following items:
 Target the right distribution
 in your debian/changelog:
 codename-security
-(e.g. jessie-security).
+(e.g. -security).
 Do not target 
distribution-proposed-updates or
 stable!
 
@@ -1155,7 +1154,7 @@ you have already used for a previous upload, or one that 
conflicts with a
 binNMU. The convention is to append
 +debXu1 (where
 X is the major release number), e.g.
-1:2.4.3-4+deb8u1, of course increasing 1 for any subsequent
+1:2.4.3-4+debu1, of course increasing 1 for 
any subsequent
 uploads.
 
 
@@ -2157,10 +2156,10 @@ this, a version of the form
 
+debXuY
 should be used, where X is the major release number,
 and Y is a counter starting at 1.
-For example, while Wheezy (Debian 7) is stable, a security NMU to stable for
+For example, while  (Debian ) is stable, a 
security NMU to stable for
 a package at version 1.5-3 would have version
-1.5-3+deb7u1, whereas a security upload to Jessie would get
-version 1.5-3+deb8u1.
+1.5-3+debu1, whereas a security upload to 
 would get
+version 1.5-3+debu1.
 
 
 
@@ -2745,7 +2744,7 @@ Version numbers are usually selected by appending
 +debXuY,
 where X is the major release number of Debian and
 Y is a counter starting at 1.
-e.g. 1:2.4.3-4+deb8u1.
+e.g. 1:2.4.3-4+debu1.
 
 
 Please make sure you didn't miss any of these items in your upload:
@@ -2771,7 +2770,7 @@ Make sure that you included an appropriate explanation in 
the changelog;
 
 
 Make sure that you've written the testing
-code name (e.g. jessie)
+code name (e.g. 
)
 into your target distribution;
 
 
diff --git a/resources.dbk b/resources.dbk
index 4b939e6..5bbcfcd 100644
--- a/resources.dbk
+++ b/resources.dbk
@@ -765,16 +765,12 @@ space on people.debian.org.
 
 Release code names
 
-Every released Debian distribution has a code name: Debian
-1.1 is called buzz; Debian 1.2, rex;
-Debian 1.3, bo; Debian 2.0, hamm;
-Debian 2.1, slink; Debian 2.2, potato;
-Debian 3.0, woody; Debian 3.1, sarge;
-Debian 4.0, etch; Debian 5.0, lenny;
-Debian 6.0, squeeze; Debian 7, wheezy;
-Debian 8, jessie;
-the next release Debian 9 will be called stretch
-and Debian 10 will be called buster.
+Every released Debian distribution has a code name:
+Debian  is called 
;
+Debian , ;
+Debian , ;
+the next release Debian  will be called 

+and Debian  will be called 
.
 There is also a ``pseudo-distribution'', called
 sid, which is the current unstable
 distribution; since packages are moved from unstable to
@@ -784,6 +780,7 @@ distribution, sid contains packages for 
architectures which
 are not yet officially supported or released by Debian.  These architectures
 are planned to be integrated into the mainstream distribution at some future
 date.
+The codenames and versions for older releases are listed on the website.
 
 
 Since Debian has an open development model (i.e., everyone can participate and
@@ -805,7 +802,7 @@ was 1.1, and not 1.0.)
 
 
 Thus, the names of the distribution directories in the archive are determined
-by their code names and not their release status (e.g., `squeeze'). These names
+by their code names and not their release status (e.g., `'). 
These names
 stay the same during the development period and after the release; symbolic
 links, which can be changed easily, indicate the currently released stable
 distribution.  That's why the real distribution directories use the

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] branch master updated (e7121c8 -> fc56ee5)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  e7121c8   Rebuild to fix issues with texlive fonts caused by 
#796120. Closes: #792009, #789391
   new  fc56ee5   Make it easier to update devref for a new Debian release.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 common.ent| 13 +
 pkgs.dbk  | 17 -
 resources.dbk | 19 ---
 3 files changed, 29 insertions(+), 20 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git