Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-30 Thread Steve Langasek
On Fri, Apr 29, 2011 at 05:15:09PM +0200, Holger Levsen wrote: On Freitag, 29. April 2011, Roberto C. Sánchez wrote: Regardless, policy states the following in section 6.8: 5. The conffiles and any backup files (~-files, #*# files, %-files, .dpkg-{old,new,tmp}, etc.) are removed.

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-30 Thread Steve Langasek
On Sat, Apr 30, 2011 at 12:02:46PM +0200, Holger Levsen wrote: On Samstag, 30. April 2011, Steve Langasek wrote: 10.7.3: If the existence of a [configuration] file is required for the package to be sensibly configured it is the responsibility of the package maintainer to provide maintainer

[PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread Ben Hutchings
--- This is based on recent discussions on debian-devel. There was not complete agreement, but I believe this reflects consensus. Ben. policy.sgml | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 91173a5..2cc2d1e

Re: [PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread Cyril Brulebois
Ben Hutchings b...@decadent.org.uk (30/04/2011): --- This is based on recent discussions on debian-devel. There was not complete agreement, but I believe this reflects consensus. Ben. policy.sgml | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-30 Thread Russ Allbery
Steve Langasek vor...@debian.org writes: (If one wishes to argue that /etc/sasldb2 is not a configuration file, then it's also a policy violation for it to be under /etc.) It's basically similar to /etc/shadow. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/

Re: [PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread Russ Allbery
Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in very long version + numbers and filenames. This

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-30 Thread Steve Langasek
On Sat, Apr 30, 2011 at 03:49:26PM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: (If one wishes to argue that /etc/sasldb2 is not a configuration file, then it's also a policy violation for it to be under /etc.) It's basically similar to /etc/shadow. I don't think

Re: [PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread sean finney
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in

Re: [PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread Osamu Aoki
Hi, On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result

Re: [PATCH] Specify policy for use of revision IDs in version numbers

2011-04-30 Thread Russ Allbery
Osamu Aoki os...@debian.org writes: This is another topic. I do not think everyone agreed yet to a particular set of numbers. The more I looked into this issue, I think followings are the possible numbers: * package file name for normal uploads: 90 characters (must) - rationale: UCS-2

Bug#624586: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-30 Thread Russ Allbery
Steve Langasek vor...@debian.org writes: I don't think that /etc/shadow qualifies as a configuration file, either; I would call it variable state information (→ /var/lib), but it lives in /etc because a) it has to be on the root filesystem, b) that's where it's always been so moving it