David Steele writes:
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote:
>> Given topydo just provides/conflicts with devtodo to provide the "todo"
>> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
>> the same functionality.
[...]
> From where I stand, I would expect the Polic
Package: debian-policy
9.1.2 recommends the following to create a directory under /usr/local:
```
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if test -e /etc/staff-group-for-usr-local ; then
if chown root:staff /usr/local/shar
Package: debian-policy
Version: 4.4.1.1
Severity: minor
While checking the upgrade checklist I noticed this new requirement:
+---
| 4.9
|Required targets must not write outside of the unpacked source
|package tree, except for TMPDIR, /tmp and /var/tmp.
+---
The wording is a bit too stric
Control: reassign -1 debian-policy
The section on initscripts has too much implementation details about
/etc/rcn.d; these are better explained by external documentation.
Also the rationale for why `DISABLED=yes` (or similar) fits better
into a footnote than the main text (IMHO).
(Policy also shou
Paul Wise writes:
> On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote:
>> Instead, if there is indeed consensus, we should change it so that it
>> no longer says that doc-base registration is recommended.
>
> We need a cross-distro cross-desktop standard for an index of
> docs before we can mov
Package: debian-policy
Version: 4.3.0.2
Severity: normal
Policy 10.5 (Symbolic links) currently has two classes of requirements:
Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).
The historic r
Sean Whitton writes:
> On Wed 02 Jan 2019 at 12:29pm +0900, Ansgar Burchardt wrote:
>> I hereby propose to drop section 1.6 Translations and the following
>> sentence: "When translations of this document into languages other
>> than English disagree with the English te
Package: debian-policy
Version: 4.3.0.1
Severity: normal
Hi,
I hereby propose to drop section 1.6 Translations and the following
sentence: "When translations of this document into languages other
than English disagree with the English text, the English text takes
precedence."
If it is wrongly tr
Adam Borowski writes:
> Thus, the wording would be (as proposed by fsateler):
>
> logind: an org.freedesktop.login1 D-Bus API implementation
>
> default-logind: should be provided by the distribution's default logind
> provider (currently pam-systemd)
So any provider of logind would have to provid
Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> That exception does not exist in Policy; there is only an exception for
>> packages provided by the init implementation itself. Policy currently
>> requires the "Loose coupling
Russ Allbery writes:
> Ansgar Burchardt writes:
>> So shipping a daemon without init scripts is better than shipping one
>> with only a systemd unit?
>
> I don't believe such a daemon package (with no init script) should be
> included in Debian at *all*, as a matt
Russ Allbery writes:
> Ansgar Burchardt writes:
>
>> a. tor@.service has no init script with the same name. This should be
>>fine. (Note: there is also both a "tor.service" and "tor" init
>>script.)
>
> Presumably this is fine for the sa
Josh Triplett writes:
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.
It's a configuration file that is not supposed to ever be changed. If
there are local changes, an admin will likely not include updates
provided by newer packages.
Ansgar Burchardt writes:
> c. It is better to ship integration with some init systems than
>no integration at all. (Including sysvinit scripts at all is not
>required, only when any other integrations are provided.)
As a special example:
DBus can start services on-demand. O
Package: debian-policy
Version: 4.2.1.2
Severity: normal
This requirement is currently included in Debian Policy:
+---
| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and equ
Ian Jackson writes:
> Apropos of discussion in #813471:
> Paul writes:
>> In addition, d-i relies on access to the apt repo for the system.
>> I can imagine other uses of that, so I added a carve-out for that.
>
> In general I think this should be done by saying that packages may
> access the apt r
Sean Whitton wrote:
> +.. _s-nonexistent:
> +
> +Non-existent home directories
> +~
> +
> +The canonical non-existent home directory is ``/nonexistent``. Users
> +who should not have a home directory should have their home directory
> +set to this value.
This is fine.
Package: src:developers-reference
Version: 3.4.18
Severity: normal
Tags: patch
Security uploads should not be uploaded to security-master.d.o, but
ftp.security.upload.debian.org or (in the future)
ssh.security.upload.debian.org.
A patch to refer to *.security.upload.d.o or ftp.security.upload.d.o
Sean Whitton writes:
> +This field should not be used for purposes other than satisfying
> +license requirements to provide full source code.
The DFSG requires source code to be provided too...
Ansgar
Hi,
as a more radical change one could also ask the question where to
maintain the maintainer information. Currently we handle this in the
source package via the Maintainer and Uploaders field, and via team
memberships.
This has several limitations: for teams, Uploaders will often be
useless (yo
Hi,
Russ Allbery writes:
> Ansgar Burchardt writes:
>> I discussed this a bit on IRC with the other ftp-masters and we came to
>> this summary:
[...]
>> 2) We wonder if the 'standard' priority can also be dropped: as far as
>>we know, it is used only by
Hi,
Russ Allbery writes:
> ftp-master folks, we're discussing eliminating the requirement that
> packages only depend on other packages with the same or higher priority
> (so important packages would be able to depend on optional packages), and
> deprecating the extra priority entirely (so everyth
Hi,
Russ Allbery writes:
> Andreas Henriksson writes:
>> 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 agree that we should *not* encourage using some `ENABLE={yes,no}` in
/etc/default/* to disable a service. This should be done via the
regular tools (update-rc.d; systemctl disable; ...).
So +1 for closing this bug as wontfix.
Ansgar
On Sat, 2016-12-03 at 06:33 +0100, Adam Borowski wrote:
> And to actually fix the issues, instead of merely dropping the
> mention and
> thus making the dependencies last forever because of inertia, I urge
> you to
> go all the way from "priority of rdepends MUST be raised" all the way
> to
> "prio
Package: debian-policy
Severity: normal
Upstart is no longer part of Debian[1] nor actively maintained
upstream. Policy should drop references to it as an alternative init
system.
I've attached a patch to remove section 9.11.1 (actually to replace it
with an empty stub to ensure there is no sect
Bill Allombert wrote:
> So to recap, Marco proposal is
>
> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..74f0a3b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8508,6 +8508,21 @@ fi
> renamed. If a consensus cannot be reached, both
> programs must be renamed.
>
Package: debian-policy
Severity: normal
Hi,
some time ago we introduced the "Extra-Source-Only" field in the
Sources indices generated by dak. This field differs a bit from
regular fields as it must not appear in the source package, but is
only added by the archive software to indicate that the
Hi,
is there still something missing for this to be included in the next
Policy update?
Ansgar
Source: developers-reference
Severity: normal
Section 6.4 "Nest practices for maintainer script" has a pathfind()
function which it suggests copy & pasting into maintainer scripts. It
suggests "which" as an alternative that requires /usr.
I think "best practices" and "copy and paste this functio
Hi,
I suggest to change
| If there are development files associated with a shared
| library, the source package needs to generate a binary
| development package named librarynamesoversion-dev, or if you
| prefer only to support one development version at a time,
| libraryname-dev.
to
| If there
Package: debian-policy
User-level applications should not use sockets below $HOME by default: the
filesystem used for $HOME might not support them, as is the case for NFS
or OpenAFS.
They should use XDG_RUNTIME_DIR (if set) or as a fallback a temporary
directory below /tmp; any location below $HO
Control: block 782993 by 152955
Hi,
the meaning of the "force-reload" action comes up again with systemd:
- systemctl implements "force-reload" as documented by LSB, that is
a service not running does *not* get started,
- the init script integration maps "/etc/init.d/X force-reload" to
"
Hi,
Bill Allombert writes:
> On Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin wrote:
>> On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote:
>> > How about the attached patch, that adds "Its value must not be empty."
>> > after "The field ends at the end of the line or at t
Jonathan Nieder writes:
> Ansgar Burchardt wrote:
>> Russ Allbery writes:
>>> In some cases, it can change maintenance decisions.
>>
>> Does this differ much from packages being picked up by other commonly
>> installed software? Say GNOME starting to depend o
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Stuart Prescott writes:
>>>> I find Priority: extra useful for at least transitional packages,
>>>> detached debug symbols, and packages conflicting with packages of
>>>> priority >= important
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Stuart Prescott writes:
>> Related to that: Given d-i/debootstrap are the main users, I think
>> having d-i ignore the priority of library packages already[1] is an
>> indication that allowing packages to depe
[ CC'ed #758234 as Stuart's questions are also related to that. ]
Stuart Prescott writes:
>> Gerrit Pape writes:
>>> Since discussion on this topic seems to have stopped, I suggest this
>>> patch to remove the priority "extra" for Debian packages.
>>>
>>> All packages that currently are of prior
Hi,
Russ Allbery writes:
> Gerrit Pape writes:
>> and helps us to keep control over the size of required and important.
>
> This is a different issue. You want oversight over what goes into
> required and important. I can certainly see why you want this.
I don't think it helps too much to con
Gerrit Pape writes:
> Since discussion on this topic seems to have stopped, I suggest this
> patch to remove the priority "extra" for Debian packages.
>
> All packages that currently are of priority "extra" shall be changed to
> priority "optional" for the reasons outlined in message #35 to this
>
Control: retitle -1 debian-policy: allow packages to depend on packages of
lower priority
Control: clone -1 -2
Control: retitle -2 Remove priority "extra", make all corresponding packages
priority "optional"
Gerrit Pape writes:
> Since discussion on this topic seems to have stopped, I suggest t
Package: debian-policy
Hi,
I suggest to drop the following paragraph from 2.5:
Packages must not depend on packages with lower priority values
(excluding build-time dependencies). In order to ensure this, the
priorities of one or more packages may need to be adjusted.
This requirement is
On 09/23/2013 10:56, Paul Wise wrote:
> On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote:
>> do you think that the attached patch would solve the problem ?
>
> There are more reasons for using Built-Using than licenses, for example:
>
> Rebuilding against updated versions of static libraries
Hi,
[ dropped -release and -wb-team, added 681289@bugs.d.o ]
Guillem Jover writes:
> On Mon, 2013-05-13 at 17:04:51 +0100, Ian Jackson wrote:
>> The real problem is that these changelog files are primarily intended
>> for human beings. They should live in /usr/share/doc, and their
>> location s
Hi,
Raphaël Hertzog writes:
> We should thus modify the policy to say:
> [...]
> 3/ that programs that want to retrieve the changelog and/or copyright
>file of a .deb file should use dpkg-deb -I
>" (or look for the changelog/copyright file in
>the directory extracted with dpkg-deb -e
On 01/06/2013 01:12 AM, Charles Plessy wrote:
> we are documenting in the Policy the Package-List field of the Debian source
> control files.
>
> Multiline field listing all the packages that can be built from
> the source package. The first line of the field value is empty.
> Each one of t
Charles Plessy writes:
> now that the implementation changed
> (http://lists.debian.org/87vcf6lbw4@deep-thought.43-1.org), I propose the
> following patch to obsolete the DM-Upload-Allowed field.
>
> This patch creates a new subsection for obsoleted fields. Alternatively we
> can
> concentra
Charles Plessy writes:
> Le Fri, Oct 12, 2012 at 09:31:24AM +0200, Ansgar Burchardt a écrit:
>> The Checksums-{SHA1,SHA256} fields were optional when they were
>> documented in Policy[1], but by now dak requires Checksums-{SHA1,SHA256}
>> to be present and listing all f
Package: debian-policy
Severity: minor
Charles Plessy writes:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
>
> In the .dsc file, these fields should list all files that make up the source
> package. In the .changes file, these fields should list all files bein
Package: debian-policy
Version: 3.9.3.1
Policy is not consistent about the requirement that perl scripts need to
use "#!/usr/bin/perl" and not, for example, "#!/usr/bin/env perl".
Policy 10.4 says "In the case of Perl scripts this should(!) be
#!/usr/bin/perl", but it's a hard requirement in the
Hi,
I agree this could be clarified in policy. In pratice we already
disallow empty package relations (besides apt choking on them there is
also an explicit check in dak for this).
Ansgar
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
On 03/02/2012 05:17 PM, Jakub Wilk wrote:
> To summarize the discussion: while there is some doubt about how the
> changelog for sponsored upload should best look like, it seems
> consensual that team names should not be used in chanelog trailers.
>
> What is the best place to document this consen
Charles Plessy writes:
> here is a proposed patch that uses a slimed version of the paragraphs proposed
> by Russ (quoted below) and keeps the original examples.
Looks good to me; seconded as well and thanks for your work.
> I agree with Russ that a binary/binary relationship may be preferrable.
Hi,
Russ Allbery writes:
> Ansgar Burchardt writes:
>> A try at this:
>
>> Some binary packages incorporate material derived from source
>> or compiled code derived from other source packages. In this case
>> this field must be used to list all other sou
Am 12.12.2011 15:14, schrieb Jakub Wilk:
* Ansgar Burchardt , 2011-12-12, 14:44:
Also, §7.1 specifies differently the architecture restrictions for
build relationship fields (Build-Depends, Build-Depends-Indep,
Build-Conflicts and Build-Conflicts-Indep) and binary relationship
fields. According
Hi,
thanks for your comment and sorry for the late reply, I forgot about
this bug for a while.
Am 11.09.2011 04:38, schrieb Charles Plessy:
thanks for documenting Built-Using in the Policy. I have a couple of
comments about your patch.
@@ -3061,7 +3061,8 @@ Package: libc6
Depends,Pr
.
I would like to have this field documented in policy, a first patch is
attached.
Regards,
Ansgar
>From be15241200d6dfa13afa9fa8e36944d1599cc6e3 Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt
Date: Sat, 10 Sep 2011 22:40:07 +0200
Subject: [PATCH] Document Built-Using field.
---
policy.s
Hi,
Charles Plessy writes:
> Le Sun, Mar 13, 2011 at 12:38:06PM +0100, Ansgar Burchardt a écrit :
>>
>> I think the wording in chapter 5 (Control files and their fields) is
>> quite unclear where multi-line fields are allowed. I am mostly
>> interested in debian/
Package: debian-policy
Version: 3.9.1.0
Severity: normal
Hi,
I think the wording in chapter 5 (Control files and their fields) is
quite unclear where multi-line fields are allowed. I am mostly
interested in debian/control in source files, so I'll just discuss this
here.
Accoring to [1] only Upl
Package: debian-policy
Version: 3.9.0.0
Severity: minor
Hi,
perl/5.8.0-7 added /etc/perl to @INC:
* Prepend /etc/perl to @INC to provide a standard location for
configuration modules:
But this addition has never been documented in the Debian Perl Policy.
I suggest to add /etc/perl to the
Package: debian-policy
Version: 3.7.3.0
Severity: normal
Hi,
there is a contradiction how to name man pages for perl modules.
Section 4.1 states
Module packages must install manual pages into the standard
directories (see Documentation, Section 2.4) using the extensions
.1p and .3pm
61 matches
Mail list logo
