ld make dak reject packages shipping files in /bin, /lib*, /sbin
to avoid introducing regressions. I find that reasonable, but others
might disagree what ftpmasters can accept/reject (I would guess at
least one person would in this case...)
Ansgar
t; restriction to all archives?
>
> Does the build daemons actually build non-free ?
Yes: allowlisted non-free packages get built on buildds.
Not allowing network access for contrib and non-free as well seems
reasonable to me.
Ansgar
On Fri, 2024-02-09 at 22:01 +0100, Bill Allombert wrote:
> On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> > with the upcoming time_t & friends 64-bit transition, dpkg-
> > buildflags
> > will be used to configure the ABI in use.
>
> This decision comes
y be mentioned in user documentation as well.)
Currently Debian Policy does not mention dpkg-buildflags at all.
Ansgar
these exist. They are
also used, both by software shipping in Debian and outside.
Dropping them would break existing software. I'm assuming the Jackson
symlink proposal would retain them for this reason instead of breaking
software for no good reason.
Ansgar
Hi,
On Sat, 2023-09-16 at 12:58 -0700, Russ Allbery wrote:
> Control: unblock 1051371 by 1050001
>
> Ansgar writes:
>
> > However, there is a proposal by Jackson for an alternative filesystem
> > layout based on symlink farms in consideration by the technical
> &
y be aware of this
policy issue in their consideration of #1050001; the resolution of
which might also cover this issue (#1051371).
Ansgar
[1]: https://bugs.debian.org/1050001#33
rs to patch this in software packaged
for Debian? Why?
I think it is fine to wait with this until buildds use merged-/usr for
builds, but I don't see any reason to spend resources on this after
that.
Ansgar
e changed. So please consider reverting
+---
| Packages that include system services must include ``systemd`` service
+---
to the original
+---
| Packages that include system services should include ``systemd`` service
+---
Ansgar
ration".
This should address concerns raise on d-devel@ that some packages might
not ship an init script. It also better covers alternative init systems
that do something more interesting than just starting the same sysvinit
scripts of old (not sure if any do).
Ansgar
in two places would at least be confusing for
users: where would users need to change settings? In the unit file? In
the tmpfiles files? Both?
Ansgar
I suggest that you try systemd-nspawn for this purpose.
>
Or podman or docker or various other things.
Plain chroots and an unclean environment which violates various
assumptions system startup scripts make are not a great way to test
stuff.
Ansgar
ot; too if the automation means
debconf as the admin might not have answered to the questions, for
example when the package is installed in an automated setup ;-)
Ansgar
hat is a change from current practice. And could be extended to
forcing /usr/local to be empty and a sane, standard environment and
contents of $HOME and anything else that could affect build results.
Ansgar
ity "required" and additional packages. An informational
| list of additional packages can be found in
| /usr/share/doc/build-essential/list (which is contained in the
| build-essential package).
+---
This only documents existing practice as practically all systems have
required packages installed.
Ansgar
inconvenient.
>
> I am not sure we have a consensus on avoiding using this feature for the
> sake of simplicity of understanding, so let's exclude that idea for now.
Sure, that seems reasonable enough.
Ansgar
e.g., for different "branches" or similar; sources building binary
packages across multiple archive areas also find strange corner cases
now and then that are not handled correctly.
Ansgar
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.
[...]
age their todo lists with, why not just have the user add a "todo"
alias to their shell or $HOME/bin?
> - name: todo.txt
> description: task management based on a standard free-form text format
This description seem to vague to me: it doesn't even mention what file
format. Does a package providing todo.txt provide any specific user
interface? Emacs can edit todo.txt files: would it qualify (even
without a "todo" executable in $PATH)?
Ansgar
On Tue, 2020-12-01 at 08:00 -0500, Sam Hartman wrote:
> > > > > "Ansgar" == Ansgar writes:
   Ansgar> using other choices of "Rules-Requires-Root" than "no" and
   Ansgar> "binary-targets". The query [1] found two uses:
Can you h
l needs to
do something sensible (probably just do nothing).
(There are other problems as a sysvinit script cannot really be a noop
for removed-but-purged packages as the LSB header still does something,
but improving that is probably not too welcome as it would require
changes in sysvinit.)
Ansg
On Tue, 2020-11-24 at 13:49 +0100, Bill Allombert wrote:
On Tue, Nov 24, 2020 at 01:37:53PM +0100, Ansgar wrote:
> > Therefore I suggest to deprecate using R³ values other than "no"
> > and "binary-targets" within Debian.
>
> What about 'Rules-Requi
³ seems overkill given there is just one real user (libcap2) and the
current R³ specification doesn't handle that usecase fully either.
Therefore I suggest to deprecate using R³ values other than "no" and
"binary-targets" within Debian.
(Unrelated: R³: no should probably be
Package: debian-policy
Version: 4.5.1.0
Severity: normal
Tags: patch
Section 11.8.4 "Packages providing a window manager" still references
the Debian menu. But the Debian menu is deprecated.
I suggest to remove the reference, for example with the patch below.
Ansgar
--- a/policy/ch-
On Tue, 2020-08-04 at 23:50 +0200, Guillem Jover wrote:
> On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
> > Ansgar writes:
> > > 10.9 Permissions and owners currently says
> > > > Files should be owned by root:root, and made writable only by the
> >
lls that is
not a conffile) should have 444 (or 555).
Ansgar
->is_valid();
'
So it is more generous than Policy either way.
Ansgar
On Fri, 2020-06-05 at 15:23 +0200, Ansgar wrote:
> So, Policy should probably:
> - Refer to RFC 5322.
> - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").
> - Allow the extensions from RFC 6532.
Maybe Policy should also refer to either `mailbox`
ensions from RFC 6532.
Ansgar
e files, systemd provides a convenient way
to allocate such a system user:
+---
| DynamicUser=
| Takes a boolean parameter. If set, a UNIX user and group pair is
| allocated dynamically when the unit is started, and released as
| soon as it is stopped.
+---[ man:systemd.exec(5) ]
Ansgar
ed unless absolutely
necessary" and later "You must not tag any packages essential before
this has been discussed on the debian-devel mailing list and a consensus
about doing that has been reached".
Ansgar
innovation to
me. Though I think it might be close to what runit or OpenRC support
currently means in Debian.
Ansgar
ies like this.
I think no option says we shouldn't use services that don't rely on
systemd as pid-1 (which also includes widely used things like udev).
Ansgar
On Fri, 2019-11-22 at 12:07 +, Simon McVittie wrote:
> On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote:
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
for directories that aren't created as above, but
by, for example, a call to `make install`.
The `/etc/staff-group-for-usr-local` flag file could also go away then.
Ansgar
x27;m also fine with alternatives such as using `CacheDirectory=`,
`StateDirectory=`, `ConfigurationDirectory=` or `LogsDirectory=` in
.service files where appropriate.
I have no opinion on implementation details so far.
As far as I understand the current GR is unrelated to adopting things
like systemd-tmpfiles.
Ansgar
tive init
systems must be able to run/understand sysvinit scripts; it's not about
whether packages must/should provided sysvinit scripts which is more
controversial.)
Ansgar
On Fri, 2019-11-15 at 16:05 +0100, Ansgar wrote:
> 9.11 states:
>
> +---
> > Alternative init implementations must support running SysV init
> > scripts as described at System run levels and init.d scripts for
> > compatibility.
> +---
>
> Does this inclu
/insserv/override,
/usr/share/insserv/override)
Does this include understanding insserv system facilities?
(The init.d script section in Policy referred to is too old to know
about any of these features.)
Ansgar
nce commit 3cfbd29f3d412894b275fbb98624d3e7d8f9dd4c:
Add explicit :manpage: markup to links to manual pages (2019-11-03 13:27:27
-0800)
are available in the Git repository at:
https://salsa.debian.org/ansgar/policy.git typo-multple-multiple
for you to fetch changes up to ce89b3c4ea96b9767264cd3589a436
hould
> +be named ``/etc/init.d/package``, and they should accept one argument,
> +saying what to do:
>
> ``start``
> start the service,
>
> Ansgar, does that look good to you? If so, it also needs one more second.
Yes, looks good to me. Seconded.
Thanks,
Ansgar
Russ Allbery writes:
> Ansgar writes:
>> How to proceed with this? Do you still require any wording changes?
>
> I think we can proceed to add a Policy "should" for including a systemd
> unit file unless someone raises objections pretty soon here. So far, I
> hav
file is RC-critical bug? Or I
> will be able to waive it with "you are welcome to contribute a patch"
> response?
Or should we consider making shipping a sysvinit script, but no systemd
unit a RC bug? Dmitry seems to be concerned that people might just
waive it away; I don't think this needs to be a RC bug, but it might
slow adoption.
Ansgar
oday? and if so, how?
Sure, changes@db.d.o still works and is the only way to configure some
settings. It is documented here: https://db.debian.org/doc-mail.html
Ansgar
he repository at ``https://example.org/repo``.
I don't understand what does from just reading this. When
`p/package` is given, which one of `p/package/debian/control` and
`p/package/control` is supposed to be used?
Ansgar
tus.
>
> and then moving this whole paragraph into 9.3.2, probably as the
> second-to-last paragraph?
Besides that I believe it's fine.
9.3.2 still has other interesting parts that I want to change (such as
suggesting editing /etc/init.d/ is a good way to disable
services). For the conffile-disliking person it also contains the
admission that conffiles are so user-unfriendly on upgrades that there
are conffiles for conffiles, i.e. /etc/default/* ;-)
Ansgar
strict and should be relaxed. There are
other paths that should be fine to be written to during the build
process, for example /dev/shm, /run/lock[1], or possibly anything
below /proc/ for processes spawned by the build process.
Ansgar
[1] Which I noticed is world-writable which I'm not sure s
ented by other operating
systems.)
> On the other hand some packages require "reboot required" information
> from other ?
It's an information for users that packages might not work properly
until reboot. There is no realistic way to avoid this in Debian.
Ansgar
t; +system.
I don't believe this is a good solution as the list of exceptions would
be cumbersome to maintain (cf. #911165).
Ansgar
Sean Whitton writes:
> On Thu 26 Sep 2019 at 09:01AM +02, Ansgar Burchardt wrote:
>> The section on initscripts has too much implementation details about
>> /etc/rcn.d; these are better explained by external documentation.
>
> Are you saying that they are *currently* better
y
place initscripts in ``/etc/init.d``. These scripts should be named
...
(with or without the text in brackets).
(I think the naming rule also isn't that good: if upstream includes some
startup scripts it might be more useful to use those, even when named
differently than the package, to match upstream documentation and other
distributions.)
Ansgar
not match (e.g bin:ifupdown).
Neither is this.
As I said before, the current requirements in policy aren't that
helpful.
Ansgar
nstance. Note that
iptables doesn't depend on the linux kernel package either.
Also sysvinit would be an "alternative init system" given the current
default.
Ansgar
.)
Ansgar
>From 58a2c3d5c7d25d70c687fa7b79515970c50b5481 Mon Sep 17 00:00:00 2001
From: Ansgar
Date: Thu, 26 Sep 2019 09:56:53 +0200
Subject: [PATCH] initscripts: packages should ship systemd units
---
policy/ch-opersys.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/policy/ch-opersys.rs
should say something about LSB headers in "Writing the
scripts", but that will be a different patch.)
Ansgar
> From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001
From: Ansgar
Date: Thu, 26 Sep 2019 08:49:28 +0200
Subject: [PATCH 1/2] move rationale to discourage old
David Steele writes:
> On Wed, Sep 25, 2019 at 12:18 PM Ansgar wrote:
>> I don't think there is a way to get such changes through the policy
>> process as Sean said (I tried to document what I see as current
>> practice in #911165). Practically the project seems to ha
said (I tried to document what I see as current
practice in #911165). Practically the project seems to have already
decided that this is fine, even for packages that don't require
systemd:
+---
| There are 1033 non-overridden instances of lintian detecting a
| service unit without an init.d script [7].
+---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ]
Ansgar
tps://www.debian.org/doc/debian-policy/_sources/index.rst.txt )
I guess the tool used for the policy document adds such a link, but the
source ends up not published in the place the tool expects. It should
probably link to the Git repository instead.
Ansgar
Sean Whitton writes:
> On Sun 14 Jul 2019 at 10:22AM +02, Ansgar wrote:
>> How should we continue with this issue?
>
> Thank you for following up.
>
> I still do not see any positive reason for deleting documentation which
> might be helpful to someone, especially when d
n't seem to have blocked anyone from submitting patches adding
those. It seems reasonable it would work the same for other init
systems.
Ansgar
ase registrations work. So I don't think anything would be list
here.
How should we continue with this issue?
Ansgar
o relocate shared libraries.
+---[ https://en.wikipedia.org/wiki/A.out ]
I wouldn't be surprised if this reference to `-fPIC` comes from the
time of switching from a.out to ELF in the last millenium; it could
probably be removed.
Ansgar
d no users (or very few users),
it just creates work for maintainers for no real benefit.
As [1] says, doc-base had 20+ years to get adopted. I think it is fair
to say that it failed to do so.
[1] https://bugs.debian.org/910783#13
Ansgar
rozen can be avoided even when the TC
sets it; I even agree that it should be avoided.
Ansgar
ty)
> or adjust the text to include this.
This is a duplicate of #152955.
Ansgar
such solutions to be used over just
forbidding to ship the directory as part of the package.
Ansgar
have to use bind-mounts instead of
symlinks; (b) would allow any directory to be a symlink, but require
tools acting on chroots to be aware of symlinks (but they have to be
that already as we sometimes require absolute symlinks already).
Ansgar
[1] https://lists.debian.org/debian-polic
d environments is in contrast a fairly
friendly failure mode. So it should not be a serious bug (whether RC or
not is something for the release team).
> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.
I doubt we have, but let's ignore that.
Ansgar
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
d be no need to put one language over others.
Ansgar
wo features currently used
> by third parties: one is the necessary hooks to start the systemd
> implementation of login1.
You can start logind without libpam-systemd, it just wouldn't know about
any session. So it is about providing hooks to register sessions with
logind.
Ansgar
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
vices. /etc/services could then be a symlink to
that file. (If services.local is empty, /var/lib/netbase/services could
just be a symlink as well to save disk space.)
Or one can just hope a reasonable admin doesn't touch these files (the
current state).
Ansgar
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
re is a init-specific job and an (in some way) equivalent
SysV-style init script then both should have the same name" remains.
Ansgar
red. It is permitted to download both binaries and/or sources.
> +However, this facility should not normally be used.
> +
> The targets are as follows:
>
> ``build`` (required)
As I said above, I think this is not a good idea.
Ansgar
/nonexistant
PATH=${standard-path} (so $HOME/bin is not in $PATH)
LC_ALL=C.UTF-8
unsetting other LC_* variables
and so on. It would also imply that just running `make -f debian/rules
binary` is not enough.
Ansgar
ftp.security.upload.d.o
instead of security-master.d.o is attached.
Ansgar
--- pkgs.dbk.ori2017-09-04 20:55:50.143885377 +0200
+++ pkgs.dbk2017-09-04 20:52:17.635087895 +0200
@@ -443,7 +443,7 @@
Security uploads
Do NOT upload a package to the security
-upload queue (on security-master.debian.org)
+upload
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
end mails
about individual packages.
For legacy purposes, the Maintainer field would then list ${source}@tra
cker.d.o and the Uploaders field could be removed.
This would also address the fact that various bits of our
infrastructure don't know about Uploaders (like bugs.d.o only
contacting the Maintainer).
Ansgar
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
#x27;ve Cc'ed -boot@ as this policy change affects them (I don't think they
have to read all of the way too long bug history though).
Ansgar
make?
Does "standard" include a text-mode MUA? emacs? vim? A small TeX
installation (optional has the full TeX distro after all)? make?
dirmngr? gcc?
I don't have an improved version though. Maybe state that it is
mostly relevant to debootstrap (or "what the installer will
install")?
Ansgar
- speaking only for himself
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
hing (I don't think we need this currently, but we
should keep the option open in case it turns out we need it).
Ansgar
is no section 9.11.1 with different
contents in the future).
Ansgar
[1] <https://bugs.debian.org/808289>
diff --git a/policy.sgml b/policy.sgml
index 9cd182b..3c75da9 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8553,47 +8553,8 @@ exec /usr/lib/foo/foo "$@"
scripts and
ween {path} andÂ
 /usr/{path} and a compatibility symlinks is needed,
 the symlink must be managed in such a way that it will not
 break when, for example, /bin and /usr/bin
 are the same directory.
Ansgar
e documented as it is
not used in "control files", but only added by the archive software.
Should it just be added as another field in section "5.6 List of
fields"?
Ansgar
Hi,
is there still something missing for this to be included in the next
Policy update?
Ansgar
ces" and "copy and paste this function" are
contradictionary. Given that /usr is *always* available when
maintainer scripts are run, using `which` should be just fine.
Ansgar
packages over versioned ones.
For versioned -dev packages, use APIVERSION instead of SONAMEVERSION as
API and ABI can change independently. This matches current practice: as
a random example: libgweather-3-dev + libgweather-3-6
Ansgar
$HOME should only be used as a
fallback.
I'm not sure where in policy such a requirement would belong: we don't
seem to have requirements for either socket use nor what user-level
applications should be doing so far.
See also [1].
Ansgar
[1] <http://standards.freedesktop.org/basedir
cy.
This makes the behaviour as defined by LSB and as implemented in systemd
a "should", making scripts behave consistent wheather systemd in used as
init or not.
Ansgar
[1] <https://bugs.debian.org/152955#35>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87618pzzu7@deep-thought.43-1.org
ntly states the
opposite of the change, i.e. that empty values are *not* allowed in
source packages whereas that should be the only place where they *are*
allowed.
Ansgar
> commit ec38643c34333231a2e179ba1e135fd2ebccbf7a
> Author: Bill Allombert
> Date: Sun Nov 23 16:16:21 2014 +
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
.)
I think it's useful to be able to change what d-i installs without
having to upload packages unrelated to d-i itself for this.
How this is implemented doesn't matter too much (besides transition
issues). If someone decides we really hate priorities, I think we could
possibly replace them wit
1 - 100 of 123 matches
Mail list logo
