Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

On Mon, 11 Sept 2023 at 07:01, Russ Allbery wrote: > > As usual, the things I notice only after I post text, even though I'd > already read it several times. > > Russ Allbery writes: > > > +Volatile and temporary files (``tmpfiles.d``) > > +- > > + > >

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

As usual, the things I notice only after I post text, even though I'd already read it several times. Russ Allbery writes: > +Volatile and temporary files (``tmpfiles.d``) > +- > + > +Some packages require empty directories, files with trivial content

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

I wrote: I believe that by choosing the wording appropriately, we can still keep this desired property of Policy while still not mandating any given implementation. Sorry, that was terribly worded. I meant that we can avoid the hassle of documenting everything dh_installsystemd does and at the

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

El 10/9/23 a las 4:09, Russ Allbery escribió: I therefore would like to propose a first: I think Policy should simply say that any package that provides a system service should use debhelper and rely on dh_installsystemd to put the appropriate commands in its maintainer scripts. (We can then

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Santiago" == Santiago Vila writes: Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió: >> I therefore would like to propose a first: I think Policy should >> simply say that any package that provides a system service should >> use debhelper and rely on

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

On Mon, Sep 11, 2023 at 12:47:15PM +0200, Santiago Vila wrote: > El 10/9/23 a las 4:09, Russ Allbery escribió: > > I therefore would like to propose a first: I think Policy should simply > > say that any package that provides a system service should use debhelper > > and rely on dh_installsystemd

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 945269 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#567033: Decide if we should continue recommending /usr/games

On 2018-06-14 11:42:22, Simon McVittie wrote: > Debian can choose to put games in the /.../games directories, or in the > standard directories /usr/bin, /usr/share etc., or any mixture of our > choice, orthogonal to whether/when we move to FHS 3.0. It's been a while since this was discussed, but

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, 11 Sep 2023 at 10:19:13 -0700, Russ Allbery wrote: > I am inclined to agree [with no longer recommending /usr/games]; > it's just one more thing for people to think about > while packaging things, and I don't think it serves much of a useful > purpose. However, the bug log has a couple of

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 19:11:30, Simon McVittie wrote: [...] > Disclosure: I am a co-maintainer with Alexandre of the game-data-packager > package, which installs proprietary game data into /usr/share/games, some > of it much larger than the vast majority of games we package in Debian; and > I think

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Luca Boccassi writes: > Two more things went missing: Simon's suggestion on the versioned > dependencies on the virtual packages, Ah, yes, I'm sorry, I talked myself out of that and then completely forgot the previous discussion so didn't say anything. My concern is that it felt like we were

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > I get the argument against bad binaries not being in PATH but we have > some tooling for that, don't we? /usr/libexec, no? /usr/libexec isn't a replacement because it's not on any user's PATH. /usr/games is intended to be added to a regular user's path but not root's,

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > I wonder if we should just do the same. I'm not sure I see the point of > having all that stuff in a separate directory, personnally, but at least > in this case we shouldn't needlessly diverge from upstream... although > in terms of upstream for bsd-games, things are

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 10:19:13, Russ Allbery wrote: [...] > I am inclined to agree; it's just one more thing for people to think about > while packaging things, and I don't think it serves much of a useful > purpose. However, the bug log has a couple of concrete objections. For the record, I actually

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote: > On 2018-06-14 11:42:22, Simon McVittie wrote: > > Debian can choose to put games in the /.../games directories, or in the > > standard directories /usr/bin, /usr/share etc., or any mixture of our > > choice, orthogonal to

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 11:25:34, Russ Allbery wrote: > Antoine Beaupré writes: > >> I get the argument against bad binaries not being in PATH but we have >> some tooling for that, don't we? /usr/libexec, no? > > /usr/libexec isn't a replacement because it's not on any user's PATH. > /usr/games is intended

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 19:57:16, Bill Allombert wrote: [...] > On the other hand, /usr/games allows: > - priviledged accounts to omit /usr/games in their path (root does not have > it e.g) I said it elsewhere but I'll repeat it here, if we want a separation there, we already have another mechanism for

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > On 2023-09-11 11:25:34, Russ Allbery wrote: >> Antoine Beaupré writes: >>> I get the argument against bad binaries not being in PATH but we have >>> some tooling for that, don't we? /usr/libexec, no? >> /usr/libexec isn't a replacement because it's not on any user's

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

On Mon, 11 Sep 2023, 17:58 Russ Allbery, wrote: > Luca Boccassi writes: > > > Two more things went missing: Simon's suggestion on the versioned > > dependencies on the virtual packages, > > Ah, yes, I'm sorry, I talked myself out of that and then completely forgot > the previous discussion so

Bug#567033: Decide if we should continue recommending /usr/games

Hi, The bespoken machine of 2015 with 64GB of SSD has been repurposed as a Buster (the "new" os at work) backporter box, but I'm still here. I agree that the games in Debian - especially the free ones - don't evolve that much, don't grow so much, but on the "contrib engine + non-free assets"

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

On Mon, Sep 11, 2023 at 09:21:56AM -0600, Sam Hartman wrote: > > "Santiago" == Santiago Vila writes: > > Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió: > >> I therefore would like to propose a first: I think Policy should > >> simply say that any package that provides a

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Bill" == Bill Allombert writes: Bill> But we do: we support debhelper 13.11.4 and debhelper 13.11.6. Bill> Even if we support a single implementation, we still need to Bill> know what is expected of it. At that level, I think the answer is roughly that if you call

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

Bill Allombert writes: > But we do: we support debhelper 13.11.4 and debhelper 13.11.6. Even if > we support a single implementation, we still need to know what is > expected of it. Policy already requires a single implementation of quite a lot of tools, does not specify a version, and does

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote: > On 2023-09-11 11:25:34, Russ Allbery wrote: > > Antoine Beaupré writes: > > > >> I get the argument against bad binaries not being in PATH but we have > >> some tooling for that, don't we? /usr/libexec, no? > > > > /usr/libexec

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Guillem Jover writes: > Seconded. Thanks! I think the wording changes subsequent to Sam's second are informative and within the changes the Policy Editor can make without seconds, so I'm proceeding with this and Sam's second and have merged this change for the next Policy release. -- Russ

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 991984

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#872587: Document the Protected field

Control: retitle -1 Document the Protected field Adam Borowski writes: > On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote: >> Do you have any idea how long we can expect to wait until dpkg supports >> the field? I would suggest that we wait until dpkg has defined >> behaviour for

Processed: Re: Bug#872587: Document the Protected field

Processing control commands: > retitle -1 Document the Protected field Bug #872587 [debian-policy] debian-policy: please document "Important: yes" Changed Bug title to 'Document the Protected field' from 'debian-policy: please document "Important: yes"'. -- 872587:

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 963524 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 1039102 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

Sam Hartman writes: >> "Luca" == Luca Boccassi writes: > Luca> Thank you, looks good to me, seconded. > LGTM too, seconded. Thanks! This has now been merged for the next Policy release. -- Russ Allbery (r...@debian.org)