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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery  wrote:

> Luca Boccassi  writes:
>
> > systemd upstream will drop support for the transitional sysv generator
> > in the near future. The transition is long finished, it's been at least
> > a decade, and it's time for the tail of packages still shipping only
> > init scripts but not units to be updated.
>
> > Tentatively this should happen within Trixie's development cycle. Of
> > course it's free software and generators are not that difficult to
> > maintain, so if someone wanted to lift the sysv generator out of the
> > systemd repository and adapt it to be a standalone binary there's
> > nothing stopping them. But I wouldn't want the systemd package to depend
> > on such a backward compat tool, so packages needing this hyptothetical
> > package should depend explicitly on it. This is just mentioned for
> > completeness, it's been at least a decade and writing a unit file is
> > beyond trivial so there shouldn't be any issue adding the few remaining
> > ones.
>
> The mass bug filing happened, and although there were some objections on
> debian-devel, I don't think any of them were blocking.  Specifically, I
> did not see anyone present a concrete plan for how to keep the systemd
> unit generator or some equivalent alive, and given that systemd upstream
> is dropping support for this feature, I believe that's the only way for
> this change to not be effective mandatory.
>
> Therefore, I think the time is ripe to proceed with this Policy change.
>
> I took a detailed look at this part of Policy today, and the whole system
> service section needs serious work.  I believe the instructions it
> currently provides for constructing package maintainer scripts won't
> actually work with a current Debian system, and most Debian packages are
> technically violating the current Policy because it hasn't been updated
> for how systemd units work today.  I started on overhauling that section,
> but it became clear that this is going to be a larger project with some
> potentially controversial decisions, so I'm going to open a new bug about
> that so that we don't block this change on that work.
>
> I made the following changes to your last diff:
>
> * Move the "should" about integrating with service management to the
>   parent section.
>
> * Explicitly say that systemd is the default init system and service
>   manager (it feels like we should say this somewhere, and I don't think
>   we already do).
>
> * Add an explicit exception for packages intended only to support
>   alternate init systems.  (As an obvious example, sysvinit isn't going to
>   ship a systemd unit, nor should it.)
>
> * Delete the paragraph suggesting that packages without systemd units
>   should write an init script, since this will no longer accomplish the
>   goal of getting that system service to work with systemd and therefore
>   no longer seems to serve a purpose.
>
> Here is what I came up with.  I think it is ready for seconds or
> objections.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:33 PM Russ Allbery  wrote:

> Control: tags -1 pending
>
> Max-Julian Pogner  writes:
>
> > consulting the debian policy manual whether it contains suggestions how
> > to best implement diversions (see `man dpkg-divert`), i noticed syntax
> > errors in the provided shell script example snippets.
>
> > a patch fixing these typos is attached.
>
> Thanks, applied for the next Policy release.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#830913: debian-policy: Allow amd64 systems without /lib64

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 2:15 PM Russ Allbery  wrote:

> Russ Allbery  writes:
>
> > It's now been about a year and it looks like this message didn't get a
> > reply, so I'm going to go ahead and close this bug because I don't think
> > we have enough information to act on it.  If there are more details
> > about my questions above, feel free to open it.
>
> For the sake of the record on this now-closed bug, I got a reply from
> Javier Serrano Polo asking if I had received a message related to this bug
> last year.  I don't remember receiving one, and it's not present in the
> BTS.  I attempted to reply to that message saying so, but the jasp.net
> mail server rejected my mail message with the following bounce message:
>
> : host
> www.jasp.net[84.126.37.22] said: 550-The message does not meet the
> trust
> level of one recipient at least 550-See
> http://www.jasp.net/smtp/trust.xhtml 550 Administrative prohibition
> (in
> reply to end of DATA command)
>
> I don't think this changes anything about the original analysis, so I'm
> leaving this bug closed, but I wanted to clarify my last message;
> apparently there is some communication blockage here.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 5:48 PM Russ Allbery  wrote:

> Gunnar Wolf  writes:
>
> > It has been four months since the General Resolution 2022/vote_003 was
> > voted¹, but it has not yet been completely adopted. The archive area was
> > created and at least a package was uploaded to it in October, but it has
> > not seen further movement. Two days ago, a call to action for moving
> > packages was sent by Cyril Brulebois², and I just sent a mail checking
> > for other places where it should be included³.
>
> > ¹ https://www.debian.org/vote/2022/vote_003
> > ² https://lists.debian.org/debian-boot/2023/01/msg00150.html
> > ³ https://lists.debian.org/debian-project/2023/01/msg00018.html
>
> > To my surprise, the non-free-firmware archive area has not yet been
> > discussed for inclusion in the Policy.
>
> > I am (now!) aware there is a clear process to get changes included in
> > the Policy, but this is the first time I do this, so please excuse me
> > for jumping all the way to "State D: Wording proposed" (of course, my
> > words can be checked and improved, particularly given I'm not a native
> > English speaker).
>
> > ⁴ https://www.debian.org/doc/debian-policy/ap-process.html
>
> > I am suggesting the following patch, which I'm attaching to this bug
> > report, and also uploaded them to my fork of debian-policy in Salsa:
>
> >
> https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0
>
> Thank you!  I also second this change, and have merged it for the next
> version of Policy, including the fixes suggested by James Addison.  I
> numbered the footnotes in chapter two so that both non-free and
> non-free-firmware could reference the same footnote.
>
> An editorial note: Gunnar's patch introduced non-free-firmware after main
> and before contrib and non-free, and after some consideration I kept that
> order because I think it reflects the high likelihood that the typical
> user will encounter the non-free-firmware archive area given the results
> of the GR.  That does mean that the contrib and non-free sections have
> been renumbered to 2.2.3 and 2.2.4, which resurrects a section 2.2.4 that
> previously was for non-US back when we had cryptography restrictions.  I
> don't think this will cause any actual problems (and one of my long-term
> wishlist items is for Policy to rely less on section numbering, which is
> inherently unstable, and switch to some sort of persistent ID), but it
> seemed worth mentioning.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:12 PM Russ Allbery  wrote:

> Package: debian-policy
> Version: 4.6.2.0
> Severity: important
> X-Debbugs-Cc: r...@debian.org
>
> As part of reviewing #1039102, I took a detailed look at Policy 9.3
> on system services and realized that it is largely obsolete and is
> not followed by most Debian packages that provide system services.
> Specifically:
>
> * There is no real documentation of systemd units except in the
>   introduction, and most of the section describes init scripts as
>   if they were the only way to start a service.
>
> * All packages are told they must use update-rc.d, but systemd units
>   no longer use update-rc.d.  They instead use deb-systemd-helper in
>   ways that are not documented in Policy and I believe are maintained
>   primarily in debhelper.
>
> * All packages are told they should use invoke-rc.d, but systemd units
>   no longer use invoke-rc.d.  They instead use deb-systemd-invoke,
>   which also supports the policy-rc.d interface.
>
> * The policy-rc.d interface is undocumented.
>
> This part of Policy is also a bit of a mess of deleted sections due to
> a desire to avoid section renumbering.
>
> I started a rewrite of this section, but quickly ran into the question
> of how to document the correct invocations of deb-systemd-helper and
> deb-systemd-invoke.  After thinking about this for a while, the
> conclusion I reached was that documenting this in Policy is both extra
> make-work that we do not have the resources to keep up with, and serves
> no real purpose for nearly every reader of Debian.  debhelper is already
> maintaining the correct code to set up systemd services in close
> cooperation with the systemd and init-system-helpers maintainers, that
> code contains temporary workarounds and other fixes that Policy is not
> going to keep up with, and it's hard to justify duplicating that work in
> a Policy statement.
>
> 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 discuss whether we should do the same
> for init scripts and dh_installinit, although its stanzas are simpler.)
>
> Previously we have tried to avoid doing this, and have maintained the
> principle that debhelper is simply an *implementation* of Policy, and it
> still falls to Policy to describe what debhelper should do.  However, I
> think it is now abundantly obvious that debhelper has considerably more
> development resources available to it than Policy has writers, debhelper
> developers are quite rightfully not waiting for things to be added to
> Policy before they can be implemented, and essentially every Debian
> package that does anything non-trivial uses debhelper now.  I also don't
> see any truly useful purpose served by dumping a wad of shell code into
> Policy that essentially no one will use because it's what debhelper would
> add for them.
>
> I have some other questions about the rewrite of these sections (such as
> how hard we should try to retain section numbering), but I think we should
> resolve this question first, since it has dramatic effects on what text
> we should write.
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> debian-policy depends on no packages.
>
> Versions of packages debian-policy recommends:
> ii  libjs-sphinxdoc  5.3.0-7
>
> Versions of packages debian-policy suggests:
> pn  doc-base  
>
> -- no debconf information
>
>

Bug#1050322: Partial versus complete replacement of a package by another

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:51 PM Russ Allbery  wrote:

> julien.pu...@gmail.com writes:
>
> > Oh. I think I had two problems:
> > (1) thinking "Replaces" meant "replaces" ;
> > (2) thinking d/control controlled packages.
>
> > Let me try to see if I'm getting at something:
>
> > (*) Replaces doesn't really mean "can be used in place of"
> > -- that would be expressed with Breaks+Provides.
>
> > (*) Replaces shouldn't come without Breaks, but doesn't imply it
> > so we have to put in both (why?).
>
> Yes, this is a good question.  I recently was confused about this myself
> despite having worked on Debian and maintained Policy and, at times,
> Lintian for years, which implies that we don't do a very good job of
> documenting the ins and outs of this.
>
> https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best
> explanation of this that I've seen.  The short summary is that the one
> case where Breaks is not required is if the package with Replaces also
> depends on a new version of the package that it is replacing.  This
> prevents the scenario described in the footnote.
>
> The other thing that's worth noting is that sometimes you want Breaks and
> sometimes you want Conflicts, and both Breaks and Conflicts are useful
> without Replaces for other reasons, so none of them can really imply any
> of the others.
>
> I also saw your other bug (#1050221) about promoting that footnote to the
> main text.  That's a partial fix, but I think we should include some
> portion of Helmut's explanation directly in Policy as well.  (We sort of
> say this, but we're not nearly as explicit about it as we could be, and we
> don't use normative language.)
>
> > (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
> > the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
> > and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
> > them or does it refuse with a clear error message?
>
> It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2
> and foo 1.2-2 is currently configured.  foo 1.2-2 has to be unconfigured
> first before the installation of foo-data 1.2-3 can procede.  (This is
> documented in Policy 7.3 where Breaks is discussed.)
>
> What normally happens is that users use apt rather than dpkg directly.  I
> believe apt will force an upgrade of foo because it sees that it is broken
> by foo-data and will not allow installation of foo-data without either
> upgrading or removing foo.  (dpkg does not do this because dpkg in general
> operates on only the packages it's told to operate on and doesn't expand
> the scope of one invocation to change other packages.)
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1030382: marked as done (encourage Vcs-Git over other Vcs-* headers)

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:39 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sat, 09 Sep 2023 19:35:06 -0700
> with message-id <87a5tu21t1@hope.eyrie.org>
> and subject line Re: Bug#1030382: encourage Vcs-Git over other Vcs-*
> headers
> has caused the Debian Bug report #1030382,
> regarding encourage Vcs-Git over other Vcs-* headers
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 1030382: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030382
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Jelmer Vernooij 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 3 Feb 2023 17:24:36 +
> Subject: encourage Vcs-Git over other Vcs-* headers
> Package: debian-policy
> Severity: wishlist
>
> Policy currently describes Vcs-* headers as something optional, but stops
> to
> endorse a particular Vcs.
>
> At this point, it seems uncontroversial to encourage use of Vcs-Git
> specifically here. Apart from technical arguments, it's the vcs that the
> majority of packages in the archive uses - and thus will have the better
> tooling, less of a learning curve for other contributors, etc.
>
> There are very few holdouts of other vcses in the archive. I count 62
> (ignoring those with an alioth URL):
>
>  * 26 on Svn
>  * 3 on Cvs
>  * 4 on Hg (2 are hg/hg-buildpackage)
>  * 39 on bzr (half of these are actually bzr and related packages, which I
> maintain)
>
> Cheers,
>
> Jelmer
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> debian-policy depends on no packages.
>
> Versions of packages debian-policy recommends:
> ii  libjs-sphinxdoc  5.3.0-3
>
> Versions of packages debian-policy suggests:
> pn  doc-base  
>
>
>
> -- Forwarded message --
> From: Russ Allbery 
> To: Jelmer Vernooij 
> Cc: 1030382-d...@bugs.debian.org
> Bcc:
> Date: Sat, 09 Sep 2023 19:35:06 -0700
> Subject: Re: Bug#1030382: encourage Vcs-Git over other Vcs-* headers
> Jelmer Vernooij  writes:
>
> > I've created a PR for devref -
> > https://salsa.debian.org/debian/developers-reference/-/merge_requests/41
>
> > Are you saying that it doesn't belong in policy because it'd be a
> > recommendation rather than a must/should (at this point?), or because
> > it's more about the workflow inside of Debian than package contents?
>
> Policy only documents the contents of source and binary packages and a few
> related topics like the archive structure and the various control files
> that come along with packages.  How packages are maintained is, so far at
> least, mostly outside the scope of Policy, which includes making concrete
> recommendations about version control systems, forges, workflows, etc.
>
> Therefore, the Developers Reference is the right spot for this.  Since
> that has been merged, I'm going to close out this Policy bug.
>
> --
> Russ Allbery (r...@debian.org)  

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:18 PM Russ Allbery  wrote:

> Enrico Zini  writes:
>
> > Hello, and thank you for maintaining the Policy!
>
> > Policy paragraph 4.9.1 has an example debian/rules which contains these
> > lines:
>
> >INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
>
> >ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> >INSTALL_PROGRAM += -s
> >endif
>
> > However, paragraph 10.1 recommends against it:
>
> >It is not recommended to strip binaries by passing the "-s" flag to
> >"install", because this fails to remove .comment and .note sections,
> >and also prevents the automatic creation of dbgsym binary packages by
> >tools like "dh_strip".
>
> > I would personally prefer if the example built on debhelper. If the
> > intention is to show what are the expectations at a lower level then
> > I wish the example had a comment saying "This snippet serves to explain
> > what are the expectations as a lower level. You usually want to use
> > debhelper instead"
>
> I looked at this snippet and I think it has worse problems than the use of
> install -s.  For example, it predates the existence of dpkg-buildflags,
> which would also handle noopt.  I'm also dubious that it serves any useful
> purpose given that nearly every package should just use debhelper.  The
> typical current Debian packager seems more likely to be confused by this
> fragment than aided by it.
>
> I'm therefore going to propose fixing this bug with the following patch,
> which is more aggressive than you propose.
>
> I think this is informative rather than normative and therefore
> technically doesn't require seconds, but I'll give this some time for
> other people to take a look and talk me out of deleting this section if
> they wish.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#991984: closed by Russ Allbery (Re: Bug#991984: Please document minimal environment variable needed for sensible-utils)

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 4:21 AM Bastien Roucariès  wrote:

> Le dimanche 10 septembre 2023, 04:33:06 UTC Debian Bug Tracking System a
> écrit :
> > This is an automatic notification regarding your Bug report
> > which was filed against the debian-policy package:
> >
> > #991984: Please document minimal environment variable needed for
> sensible-utils
> >
> > It has been closed by Russ Allbery .
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Russ Allbery <
> r...@debian.org> by
> > replying to this email.
> >
> Seems sensible note that linux manpages mandate now some behavior for
> EDITOR, PAGER and VISUAL
>
> Bastien
>
>

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:42 PM Russ Allbery  wrote:

> This patch from a while back is still waiting for one more second before
> it can be merged for the next Policy release.  It previously got one
> second from Wouter.  I revised the patch to mention the experimental suite
> as well as the backports suites.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 5:57 PM Russ Allbery  wrote:

> Samuel Thibault  writes:
>
> > I didn't find a previous discussion on this: it would be useful to
> > support negated architecture specifications in the debian/control
> > Architecture field, so that we can e.g. write:
>
> > Architecture: !s390 !s390x
> > (for xorg stuff)
>
> > Architecture: !hppa !hurd-any !kfreebsd-any
> > (for java stuff)
>
> > and even things like
>
> > Architecture: linux-any kfreebsd-any !hppa !m68k-any
>
> > which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> > and not m68k-any ]. I.e. if no positive specification is set, an "any"
> > positive specification is assumed.
>
> > That would help to remove quite a few entries of
> > https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
> > and avoid packages with some java bits to have to hardcode the list of
> > ports on which java jni bindings packages should be built.
>
> > I guess support would be needed in dpkg, lintian, etc.
>
> Hi Samuel,
>
> I agree that this would be useful.  This has come up frequently over the
> years, and back when I was maintaining architecture-specific packages, the
> lack of this feature was often annoying.
>
> But (as may be obvious from the long delay in even getting a response),
> Policy can't drive the implementation of this change and therefore
> probably isn't a good place to start with the request.  I think it would
> need to start with dpkg and ftp-master (for DAK).  I'm therefore probably
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.
>
> If I misunderstood the current state, please do let me know.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 2:33 PM Russ Allbery  wrote:

> Guillem Jover  writes:
>
> > Seems I missed another file:
>
> >   * .changes:
> > policy → «upload control file» / «Debian changes file»
> > dpkg   → «upload control file» / «.changes control file» /
> >  «Debian .changes file» / «Debian changes file»
>
> [...]
>
> > For changes I think something like the following might be a more clear
> > option (and has the minor bonus of aligning perfectly on the first
> > words! :), with it mentioning explicitly this is about changes being
> > uploaded, and that it is a control file (but I'm not sure I'm entirely
> > convinced about it):
>
> > * .changes:   «Debian upload changes control files»
>
> [...]
>
> > I've also found instances of «record» and «section» referring to fields
> > or stanzas.
>
> [...]
>
> > I also recalled another term that has always seemed very confusing in
> > context: «control information files» or «control information area». For
> > example in a sentence such as “the control file is a control information
> > file in the control information area in a .deb archive”. :) This also
> > seems confusing when some of the files in the .deb control member are
> > not really “control files” with a deb822(5) format.
>
> > My thinking has been going into calling these as the «metadata files»,
> > and being located in either the  «metadata part of the .deb archive» or
> > explicitly the «control member of the .deb archive», in contrast to the
> > filesystem part. In dpkg I'd be eventually switching to meta/metadata
> > and fsys/filesystem, from control or info and data. I've added a patch
> > with the proposed change, but again nothing set in stone, and I'm again
> > open to discussing pros/cons of this.
>
> > Attached the proposals for discussion/review, and I might again have
> > perhaps missed instances or similar.
>
> All of these changes seem straightforward and uncontroversial to me, and
> there are huge advantages to using consistent terminology between Policy
> and dpkg.  I have applied all of them for the next Policy release.  Thank
> you!
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:33 PM Russ Allbery  wrote:

> Here is an updated proposed change for this bug, incorporating Guillem's
> suggestions.  It is ready for seconds.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

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

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:54 PM Russ Allbery  wrote:

> Luca Boccassi  writes:
>
> > Sure, updated as suggested.
>
> I have a bunch of minor wording fixes that I'd want to make at this before
> merging, but that should be straightforward to do.  Before I invest the
> time in that, I want to check the opinions of everyone else following
> along and see if the semantics of Luca's change have general approval.
>
> Could folks take a look at this patch and see if the basic gist of it is
> something that they would second (or, for that matter, is something they
> would object to)?  I think I would second it (with wording adjustments),
> with one caveat mentioned below.  The whole thing is at:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#295
>
> Luca, am I right that service directories are specific to, well, services?
> If so, what would you think of moving them to Policy 9.3 alongside the
> other discussion of systemd units?  They feel out of place here, since
> packages that do not use services cannot use this functionality, and
> there's already a statement in the tmpfiles.d section pointing to them as
> more appropriate for services.
>
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, should not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +`_
> > +interface.  Files and directories under ephemeral filesystems such as
> > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets.
>
> I understand the empty directory part, but I don't believe "files that are
> located under /var" is correct unless you specifically mean *empty* files
> (and even then, I'm not clear on precisely when this would be needed).
> For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
> maintainer script, and I can see no possible way that action could (or
> should) be handled by the tmpfiles.d mechanism.
>
> What am I missing?
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#970234: consider dropping "No hard links in source packages"

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 1:45 PM Russ Allbery  wrote:

> This patch is still waiting for one more second.  It was previously
> seconded by Helmut.
>
> Russ Allbery  writes:
>
> > Here is a patch dropping the restriction on hard links in source
> > packages that I think is ready for seconds.  I'm copying Guillem for his
> > review, in case there's some dpkg concern.
>
> > From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> > From: Russ Allbery 
> > Date: Thu, 22 Sep 2022 19:15:52 -0700
> > Subject: [PATCH] Allow hard links in source packages
>
> > It's not clear why this restriction was in place, and Debian
> > included a package containing hard links without anyone noticing
> > in the last release.
> > ---
> >  policy/ch-source.rst | 11 ++-
> >  1 file changed, 2 insertions(+), 9 deletions(-)
>
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index c7415fc..a7df539 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably
> possible.  [#]_
> >  Restrictions on objects in source packages
> >  --
> >
> > -The source package must not contain any hard links,  [#]_ device special
> > -files, sockets or setuid or setgid files.. [#]_
> > +The source package must not contain device special files, sockets, or
> > +setuid or setgid files. [#]_
> >
> >  .. _s-debianrules:
> >
> > @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series``
> for any ``foo``.
> > would be nice if the modification time of the upstream source would
> > be preserved.
> >
> > -.. [#]
> > -   This is not currently detected when building source packages, but
> > -   only when extracting them.
> > -
> > -   Hard links may be permitted at some point in the future, but would
> > -   require a fair amount of work.
> > -
> >  .. [#]
> > Setgid directories are allowed.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Edward Little]

Unsubscribe:

 e.little...@gmail.com

On Wed, Sep 6, 2023 at 5:54 PM Luca Boccassi  wrote:

> Package: debian-policy
> X-Debbugs-Cc: j...@debian.org hel...@subdivi.de
>
> Debian only supports merged-usr since Bookworm. We should update policy
> to reference /usr/bin/sh and similar paths to describe recommended
> shebangs for scripts.
>
> I heard many times the policy maintainers mention something along the
> lines of 'policy should not be a hammer to beat other maintainers
> with'. Today I saw policy being used to force a maintainer to re-add
> support for the deprecated and unsupported split-usr filesystem layout,
> as 'policy only mentions /bin/sh, not /usr/bin/sh'.
>
> So let's update the policy to refer to modern and supported filesystem
> paths as adopted by Debian de-facto and de-jure, and stop other
> maintainers from getting beaten with it.
>
> Patch attached and also pushed to
> https://salsa.debian.org/bluca/policy/-/tree/bin_sh
>
> --
> Kind regards,
> Luca Boccassi
>