Bug#1074014: encode mandatory merged-/usr into policy

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:


Helmut> Questions: 1. Do you agree that policy should be changed?
Yes.
The TC has effectively set policy here already, and while they did
not  use their power under 6.1.1 to actually officially set project
policy, their position has been clear.


Helmut>  If yes:

Helmut>  2. Do you agree that policy should prohibit installing into
Helmut> aliased paths?

Yes.

3.

Helmut> Do you agree that the current progress is
Helmut> sufficient for changing policy? If not, when can we change
Helmut> policy?

I am not sure I agree with this question, but I agree with a simpler
question: should we change policy now.

Helmut> 4. Do you agree with the proposed wording? Can you
Helmut> suggest improvements?

I have no objections to the wording.

Helmut> 5. Given earlier disagreement on this
Helmut> matter, should we discuss this matter in a wider setting
Helmut> such as d-devel?

No, please no!
If there ends up being disagreement, the TC should use its policy making
powers and put this to bed.


signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Sam Hartman]

> "Aurelien" == Aurelien Jarno  writes:

Aurelien> If we go that route, here is a proposed alternative patch:

Aurelien> --- a/policy/ch-source.rst
Aurelien> +++ b/policy/ch-source.rst
Aurelien> @@ -338,7 +338,8 @@
Aurelien>  For example, the build target should pass 
``--disable-silent-rules``
Aurelien>  to any configure scripts.  See also :ref:`s-binaries`.
 
Aurelien> -For packages in the main archive, required targets must not 
attempt
Aurelien> +Except for packages in the non-free archive with the 
``Autobuild``
Aurelien> +control field unset or set to ``no``, required targets must not 
attempt
Aurelien>  network access, except, via the loopback interface, to services 
on the
Aurelien>  build host that have been started by the build.

Seconded.


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sam Hartman]

> "Josh" == Josh Triplett  writes:



I tend to agree with  Sean that your rationale is not convincing.
It sounds like you want to use policy as a stick to hit people
over the head and say "policy is not a stick."

I get the impression that you are trying to shift the status quo
somehow, and remove flexibility and replace it with certainty.

Let's take installing info files.
Yes, the policy around info files is optional.
But if you have info files, I think it would be a great idea if you
installed them.
(And if you are going to do that, I think we are all agreed you should
follow policy in how you do that.)

You appear to be wanting to say that the presence of the info policy is
entirely neutral.
And I don't quite think that's true.

It could mean:

1) hey it's there if you want to install info files

2) Hey if you've got info files go install them and use this great
mechanism for doing so.

3) Hey, if you're looking for how to document your software strongly
consider info because we have a way of dealing with info.

I think you're arguing that globally unless policy says otherwise we're
at 1 above.
For info I think we're closer to 2, but probably somewhere between 1 and
2.
In the past, we were probably definitely at 2 and probably somewhere
between 2 and 3.
It has shifted over time as the set of software without texinfo
documentation increased, as the limitations in info format became more
important, and as html became more of a common format.

I think the kind of language you propose to add to policy harms rather
than encourages that sort of shift over time.

I think arguments of the form we have an approach for handling this in
policy, and uniformity is good, so please use this approach are
sometimes good.
I think your language would try and cut off those arguments more than
they should be cut off.
I also understand those arguments are sometimes bad.  As an example,
arguments of that form were made in favor of the Debian menu system long
past the time when desktop files were a better choice.

I suspect there are similar issues with cron files.  Five years ago,
even if policy didn't encourage cron as the preferred mechanism for
periodic tasks, it probably was the right choice.  Saying use cron
because we have a cron policy was not and should not be a valid
argument.  Saying that in a multi-init-system world there are
complexities around using something besides cron, and we've thought
through how to handle cron, so it's probably a good choice probably was
a compelling argument five or six years ago.  We probably haven't
thought through the implications of using something other than cron in a
multi-init-system world and making sure everything works well.  What has
changed is that it's not clear we're really in a multi-init-system-world
any more, and systemd has thought through the implications of periodic
tasks in a systemd world.

But I think the kind of language you proposed would be used to treat
arguments like "if you use cron it will work better for sysvinit; we
care about sysvinit; so do that," as "we talk about cron in policy, so
use it."
The second argument never has been valid.
The first argument is one I think should be valid in form, although at
the current time I think it is liked based on a false premise.
The second argument can be dismissed because of its form.
I think the first argument requires more consideration, and I think your
proposal would remove that consideration, even if reworded.


--Sam


signature.asc
Description: PGP signature

Bug#1064454: debian-policy: Restrict deb822 field names more

[Sam Hartman]

> "Niels" == Niels Thykier  writes:

Niels> Simon Josefsson:
>> Would it make sense to change this to use an inclusive list of
>> permitted characters instead?  How about checking the field names
>> that is in use today, and construct a regexp of permitted symbols
>> out of that?  Starting point: [A-Za-z][A-Za-z0-9-_]*
>> 
>> /Simon

Niels> That is an option and would work for me.

I'd support something along these lines--an inclusive description rather
than an exclusive description.

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

[Sam Hartman]

> "Sean" == Sean Whitton  writes:
Sean> In general, I agree with Santiago.  I find Policy's current
Sean> scope and working process effective, and not especially
Sean> ambiguous.  I think everyone should read it during the NM
Sean> process, if not sooner.

Sean> Russ has concretely considered these issues much more than me,
Sean> and Niels has worked extensively on an implementation, and I
Sean> have not.  These things count, so my sense that things are
Sean> broadly okay as they are only goes so far.

I agree with the above.
When Russ brought up concerns I didn't want to add stop energy to making
things better.
But I also am generally happy with policy today.  I find it useful and
refer to it often.  I find that with almost all of my NM applicants I
end up asking them to look at policy at various points in the process
and they do not run into trouble using the document.
The only reason they did not before is they were not in the practice of
doing so.

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> At least the dpkg behavior seems entirely
Guillem> correct to me and required for safe upgrades (

Can you help me understand the sentence above?
Where is the case where this behavior is needed for safe upgrades?
(I am asking out of curiosity; I'm guessing it's some corner case with
essential packages, but I would like to understand.)

--Sam

Bug#915583: debian sphinx styling: second attempt

[Sam Hartman]

>>>>> "Stéphane" == Stéphane Blondon  writes:

Stéphane> Le ven. 3 nov. 2023 à 15:43, Sam Hartman
Stéphane>  a écrit :
>> >>>>> "Sean" == Sean Whitton  writes:
>> 
>> I'm happy to test with Orca on Firefox on Debian.  Feel free to
>> point me at a URL.
>> 


Stéphane> You can test it at: http://stephane.yaal.fr/tmp/policy/

Given a quick look, appears okay to me.

Bug#915583: debian sphinx styling: second attempt

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> - it would be good to do some accessibility testing of some
Sean> kind, at least with screenreaders.  But maybe the fact that
Sean> you've based your theme on an existing, popular Sphinx theme
Sean> means this is covered?

I'm happy to test with Orca on Firefox on Debian.
Feel free to point me at a URL.

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Aside from more practical considerations, shipping /var
Luca> content in packages is problematic because it's supposed to be
Luca> local variable data,

I agree with the above.

Luca> that can be removed without breaking a
Luca> system.

Says who?
Where?
Do we have any agreement within Debian that is true for Debian systems?
If so, where?  This is the first I am hearing about the idea I should be
able to delete local variable data and have the system  still work.

If you're talking about *empty directories in /var* or *cache
directories in /var*,
I support that as a goal.  I think it is a new goal though, and I'm
uncomfortable stating it as a reality.
(I think tmpfiles.d helps us achieve that and that's one of the
compelling reasons for tmpfiles.d).

But WRT other data in /var, I don't think we've agreed that being able
to delete it is a goal.

Bug#1051371: Post-/usr-merge paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Wed, 13 Sept 2023 at 04:48, Russ Allbery  wrote:
>> 
>> Control: retitle -1 Post-/usr-merge paths for script interpreters
>> 
>> Simon pointed out that this bug is not yet ready to act on, which
>> was very helpful.  Thank you.  However, presumably the buildds
>> will be /usr-merged at some point in the not-too-distant future,
>> and we do need to decide what to do after that point.

Luca> While that could be said for the original revision, in my view
Luca> that's not really the case for the latest that I posted?

Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120

Luca> So I would prefer if this was a clone rather than a
Luca> retitle/repurpose.  Unless I'm missing something, the changes
Luca> linked above should be uncontroversial and simply remove
Luca> excessively normative language in what are essentially
Luca> examples that should have been taken as such - and that
Luca> currently are not. So, could that be taken forward
Luca> independently of the problem you define below?

I agree the above is uncontroversial and would support including it in
policy now.
I don't think it needs seconds because it is non-normative.

(As an aside, reading the summary, I expected to find the patch
something I was not entirely happy with.  I was planning to hold my
nose, and neither support the patch nor object.  However, since you
brought it up again, I read the full patch and find I like the patch a
lot better than your summary of it:-)


signature.asc
Description: PGP signature

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

[Sam Hartman]

> "Daniel" == Daniel Gröber  writes:


>> Any configuration files created or used by your package must
>> reside in /etc.

It's fine for packages to store defaults outside of /etc.  But that 's
only true if you can override those defaults by placing a file in /etc.

Bug#1051371: Post-/usr-merge paths for script interpreters

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> with a narrower issue).  Several other people were, I think,
Russ> arguing for (a), but I'm not sure if they would continue to do
Russ> so when it's put in these terms.

It's hard for me to express what I was advocating for in the terms you
have adopted.
I think you've  advanced the discussion significantly by making it clear
where the difficulty is, which will help me focus my argument.


Russ> If someone wants to argue for (a) or (c), I think the biggest
Russ> problem with either of them is an enforcement mechanism.

My problem with (b) is that I value interfaces and that  especially for
/bin/sh I do think that /bin/sh is more portable as an interface path
than /usr/bin/sh.
I care a lot that we use /bin/sh in our documentation and examples
(especially in policy).
I care a lot that we point out that the reality of the situation is
people  will see other paths.
At least for things traditionally in /bin I do not want to encourage
those other paths, but I also don't think it is often a good use of
project resources to "fix" those other paths.
In some cases (for example what version of a path autoconf detects), I
think that patching individual packages to detect a particular path
would be net harmful.

So I want to argue for (a) with no  enforcement mechanism in packages.

1) Policy should encourage /bin paths for binaries traditionally in
/bin. (At a minimum I'd like to see this for /bin/sh and /bin/bash).
That at most makes it a minor bug if you don't follow that
encouragement.

2) The examples in policy should use the standard interface paths.
(This is the thing I care most about).

3) I'd like to see policy point out that /usr/bin paths will end up
being used, and packages SHOULD work regardless of which path is used.

I think there are some complexities here.  Imagine someone writes a tool
to determine if something is a shell script.  If it's security
sensitive, I think it is important that it work both for /bin/sh and
/usr/bin/sh.

If it's a syntax highlighting program and it only detects
/bin/sh as a valid shell script, I'd be okay if the maintainer didn't
want to fix it but instead said "fix your shell scripts if they say
/usr/bin/sh."  (I think the maintainer would be doing a better job if
they supported both).  But I would not be comfortable with a syntax
highlighting tool pushing people toward /usr/bin/sh.



signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

I don't know if this needs seconds, but I reviewed all the text and it
looks good.
If seconds are required, I second.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "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
dh_installsystemd, then any units in the package installation directory,
or any units matching certain file patterns in the debian directory will
be installed and if appropriate enabled.


I understand there's some work to do:

* do we support units in /lib/systemd/system, /usr/lib/systemd/system,
  or both.

* What are those filename patterns for finding service units under
  debian?

* You might implicitly call dh_installsystemd via dh

I think Russ might be arguing that we should actually push all that out
to the Debhelper documentation.  I'd support that, although I understand
that makes the debhelper 13.4 vs 13.6 issue more relevant.  I'd also
support describing a bit of the interface between debian/rules and
debhelper wrt systemd units if it allowed us to move forward.

My argument is that even if we support multiple versions of debhelper,
we do not need to define the interface between debhelper and systemd in
policy: we do not need to specify deb-systemd-helper and
deb-systemd-invoke.

--Sam

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

[Sam Hartman]

> "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 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.)

Santiago> Hello. I don't like this approach, and I believe we are
Santiago> mixing two different things here. One of them is our
Santiago> ability (or lack thereof) of policy to catch up with real
Santiago> development done elsewhere. Another one is the fact that
Santiago> policy does not mandate any given implementation.

The question in my mind is whether it is valuable to support multiple
implementations, and I think the answer is no.

In the past, there was not a preference for using debhelper.  So, back
then, we did need to support multiple implementations of debian/rules,
and we needed to specify the things debhelper did.

Having a specified interface like policy is expensive.  I know; I've
spent a good chunk of my life working on various protocols and
standards.
Having specified interfaces brings value when you need multiple
implementations and in a few other cases, like where you need to plan
for certain forms of extensibility or isolation.

There's a part of this where we do need an interface.  We will have
multiple packages wanting their debian/rules to install systemd units.
So, we do need to at least say or imply that if you stick systemd units
in the right place and call dh_installsystemd, then your systemd units
will be properly handled.

But today, we have a policy preference for using debhelper.  We do not
need multiple implementations of debhelper.  There does sort of need to
be an interface between debhelper and systemd if for no other reason
than to allow for systemd to change and to control which details are
hard-coded in maintainer scripts.  But if we agree that we do not need
multiple implementations of debhelper, the policy team does not need to
be part of defining that interface.  We can be more efficient by not
being involved in that process.  Also, we can do a better job of
focusing on the interface that the project does care about (how to tell
debhelper to install your systemd units) and not confuse people with the
details between debhelper and systemd.

Also, by explicitly acknowledging that the deb-systemd-helper and
deb-systemd-invoke interfaces are effectively between debhelper and
systemd, those interfaces can be simpler because they do not need to
allow for multiple implementations of debhelper or systemd.

In effect by making this decision, we are strengthening our preference
for saying packages should use debhelper.  For a significant class of
packages (those with service units) there really will be no easy
alternative.  And if we go down that route, over time, we will probably
prefer debhelper more and more, and it will be less possible to generate
a policy-compliant package that does not use debhelper.

I think that's desirable.
I think we can still find ways to experiment with new more declarative
ways of handling package building.  But I think that having more
uniformity in the cases where we have a single solution that has broad
support will make things easier for everyone.

Put another way, having multiple implementations is often very expensive
in terms of interface complexity, testing complexity, and especially
complexity that developers need to deal with.
In this instance, I do not think that cost is justified.

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I therefore would like to propose a first: I think Policy
Russ> should simply say that any package that provides a system
Russ> service should use debhelper and rely on dh_installsystemd to
Russ> put the appropriate commands in its maintainer scripts.  (We
Russ> can then discuss whether we should do the same for init
Russ> scripts and dh_installinit, although its stanzas are simpler.)

For a variety of reasons, I support this.


--Sam

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>> 
>> Russ Allbery  writes:
>> 
>> > -If a service unit is not present, ``systemd`` uses dependency
>> information > -contained within the init scripts and symlinks in
>> ``/etc/rcn.d`` to decide > -which scripts to run and in which
>> order.  The ``sysv-rc`` runlevel system > -for ``sysvinit`` uses
>> the same symlinks in ``/etc/rcn.d`` to decide which > -scripts to
>> run and in which order at boot time and when the init state (or >
>> -"runlevel") is changed.  See the ``README.runlevels`` file
>> shipped with > -``sysv-rc`` for implementation details.  Other
>> alternatives might exist.  > +``systemd`` uses dependency and
>> ordering information contained within the > ++enabled unit files
>> to decide which services to run and in which order.  > +The
>> ``sysv-rc`` runlevel system for ``sysvinit`` uses the same
>> symlinks in > +``/etc/rcn.d`` to decide which scripts to run and
>> in which order at boot > +time and when the init state (or
>> "runlevel") is changed.  See the > +``README.runlevels`` file
>> shipped with ``sysv-rc`` for implementation > +details.  Other
>> alternatives might exist.
>> 
>> And of course I have to post the diff to see the bugs.  The part
>> that says "uses the same symlinks" should now say "uses
>> symlinks".

Luca> Thank you, looks good to me, seconded.

LGTM too, seconded.



signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie  wrote:
>> 
>> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
>> > 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
>> 
>> I'm not Luca, but I think you're correct here.

Luca> Moved as suggested. Also incorporated your suggestion on the
Luca> versioned virtual package dependency verbatim.

>> > Luca Boccassi  writes: > > +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.
>> 
>> In general tmpfiles.d handles files that exist only as metadata:
>> symbolic links (for which the target is the only interesting
>> fact), empty files (for which the existence and
>> ownership/permissions are the only interesting facts),
>> directories (ditto) and so on.
>> 
>> It can also handle files that have static initial contents that
>> do not vary between systems, but can change in a system-specific
>> way later, with initial contents either hard-coded in the
>> tmpfiles.d snippet (for short text strings) or copied from
>> somewhere below /usr (canonically /usr/share/factory).
>> 
>> Files generated by non-trivial imperative code, like
>> machine-specific initial contents (/var/lib/dbus/machine-id) or
>> some sort of compiler (/var/lib/gnubg/gnubg_ts0.bd, as far as I
>> can tell), are out of scope for tmpfiles.d, so I think you're
>> right to be concerned that Luca's wording as written is asking
>> gnubg to do something that is unimplementable.
>> ch-maintainerscripts.rst has the same issue.
>> 
>> Perhaps "files with trivial contents that are located under /var"
>> would be a good wording that is not overly specific about
>> implementation details, covers the 90% case, and leaves room for
>> exceptions by declaring packages like dbus and gnubg to be
>> non-trivial?

Luca> I have reworded as suggested, citing symlinks or short fixed
Luca> strings as examples.

I second this patch, and do not need to additionally review Russ's
minor rewordings

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated proposed change for this bug, incorporating
Russ> Guillem's suggestions.  It is ready for seconds.

Russ> -- Russ Allbery (r...@debian.org)
Russ> 

I have reviewed the patch; I support the idea and second the specific
wording.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> Secondly, and less importantly, while I appreciate it's not
Luca> how you handle policy changes, the way the rest of the
Luca> distribution works is by 'building consensus' on mailing
Luca> lists. Now I don't particularly like it, but it is what it
Luca> is. And that means if somebody comes up with the most
Luca> egregious nonsense like, to pick a completely fictional
Luca> example, "hey folks, usr-merge broke docker, rsync and
Luca> ansible, we need to revert it", and it is left unchallenged,
Luca> then it becomes doxa.  So it has to be challenged. Every
Luca> time. After half a decade, you don't think _that_ is
Luca> exhausting?


Thanks for sharing this.
I understand what you've been doing a lot better now.  And if it is
actually true that you need to challenge these assertions every time,
your behavior makes more sense to me.

However, it's been my experience that challenging these assertions every
time is unnecessary.  It actually makes it harder to judge consensus and
keeps discussions alive longer than they need to.
I actually think that there are cases where if you had said less, a
consensus you would have liked just fine would have emerged faster  than
has happened.
Often when someone says something rediculous in a consensus discussion
it is best to let it fall into a void of silence.
Challenging it can sometimes just give it energy.

I would be very open to helping you (or anyone) explore how to work more
efficiently in a consensus environment and how to espace from a
consensus discussion when consensus is the wrong tool.
I realized that I focused a lot on consensus during my term as DPL.  A
lot of that was that I was hoping to help people explore how to approach
consensus discussions better (and because it was the right tool for some
of those discussions).
But there are a lot of discussions where consensus is the wrong tool.
And now that we've leveled up how we approach consensus discussions,
perhaps we should level up how not to have them:-)


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> I would. Having two paths for the same thing is a technical
Bill> debt going forward.

I think the TC has made it clear we're committed to usrmerge at this
point, and I think that one of the drivers behind usrmerge is that we
gain more from having both /bin/python and /usr/bin/python work than we
lose by having two paths.
I understand people disagree,
but I think we should fall in behind the TC decision and accept we've
decided that in this instance we value aliasing.

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

[Sam Hartman]

>>>>> "Ansgar" == Ansgar   writes:

Ansgar> On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote:
>> > > > > > "Luca" == Luca Boccassi  writes:    
>> Luca> /bin/sh is not universally compatible with non-Linux OSes.
>> 
>> I claim it is more compatible.

Ansgar> Why should that matter to Debian?


Debian has traditionally valued supporting common interfaces like posix,
fhs, Linux ABIs, etc where that makes sense.
We recently had a discussion of the value of interfaces in  the
discussion of changing the ABI to make merged /usr easier, and I do not
want to revisit that.

I do value this sort of interface stability, and Debian's alignment with
my values is one of the things that drew me to Debian.

So, yes, I do believe we should support encouraging portability where
that is reasonable for us.
I admit that I care more about OSes like FreeBSD than Mac OS.

More over, when merged /usr was presented to the project, it was
presented as a way to move the physical locations on files and as a way
to create an alias so that we didn't need to argue when different
distributions  made different decisions about /bin vs /usr/bin.
It was not presented as a change to common interface paths like /bin/sh.

This request is new, and given the politics, is something I find highly
problematic.
It is not abusing maintainers to ask them to respect long-standing
interfaces like the location of /bin/sh.
As Simon has pointed out, in a number of cases it is still actually RC
because it can break builds.
It is not abusive to ask maintainers to fix issues that prevent their
packages from building.
We make mistakes.
It is not abusive to get the severity of a bug wrong or even to disagree
with the severity of a bug.

I am sympathetic to the idea that after buildds are updated, we we might
want to reduce the severity of not using longstanding interface paths,
and in some cases not even treat it as a bug.
I reject the idea that /usr/bin/sh should be preferred over /bin/sh or
even the idea that it should be equally preferred.
I am open to the idea that we may not care to record that as a bug or
spend the time fixing it.

However, the tone and approach in this discussion does not encourage me
to participate.
If the current tone continues, I will use up the energy I have for
working toward a compromise and simply stand behind my support of
longstanding practice and  support of portable interfaces.

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> How would such a change look like?

I looked at your patch.

In most of the cases you are changing non-normative language.
That is, parts of policy that do not create a requirement.
For example:
>Scripts may assume that "/bin/sh" implements the POSIX.1-2017 Shell
>Command Language  [7] plus the following additional features not
>mandated by POSIX.1-2017.. [8]

That creates no requirement on a package.

>* The term *may* and the adjective *optional* are used to clarify
>  cases where it may otherwise appear that Policy is specifying a
>  requirement or recommendation. In those cases, these words describe

I.E. in the cases you adjust, I think it is already
not a bug, and it would be inappropriate to use existing policy language
to complain about which interpreter path people use.

There is one case however where I think your patch adjusts normative
language.

I propose the following adjustment to your patch.  Rather than mandating
a particular path for a csh interpreter, make it clear that the policy
requirement is that the csh script start with a #! line rather than
simply assuming csh will interpret the script as was all too common back
in the days of csh:

@@ -266,7 +266,7 @@ including ``open``, ``print``, ``close``, ``rename`` and 
``system``.
 Programming Considered Harmful*, one of the ``comp.unix.*`` FAQs, which
 can be found at http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/. If
 an upstream package comes with ``csh`` scripts then you must make sure
-that they start with ``#!/bin/csh`` and make your package depend on the
+that they start with the path of a csh interpreter such as ``#!/bin/csh`` and 
make your package depend on the
 ``c-shell`` virtual package.

 Any scripts which create files in world-writeable directories (e.g., in

I think the other hunks of your patch are unnecessary to avoid policy be
used to create bugs in this space.

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> /bin/sh is not universally compatible with non-Linux OSes.

I claim it is more compatible.


Luca> Also I thought that policy should not be used to beat other
Luca> developers (it is because of this) and it should reflect the
Luca> common practices adopted in Debian (it does not because of
Luca> this). Is that no longer the case?

I'd consider it a non-RC bug if someone were manually writing
#!/usr/bin/sh

We can debate about normal vs minor.

I do not think it should be a bug if some automated build process found
/usr/bin/sh and stuck that into a script.
I'd support a policy change to make that clear.

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Debian only supports merged-usr since Bookworm. We should
Luca> update policy to reference /usr/bin/sh and similar paths to
Luca> describe recommended shebangs for scripts.

I do not support this change.  /bin/sh should still be the recommended
interface path for the posix shell.  Among other reasons, it promotes
compatibility between Linux and other posix architectures.  Besides
that, I suspect there are cases where tools look for /bin/sh in a #!
line and do not accept /usr/bin/sh.

I absolutely agree that the physical path of the posix shell should be
/usr/bin/sh.
I disagree that we should be changing interface paths for items
traditionally found in /bin.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

>> I consider this proposal to be premature. Policy should document
Luca> current
>> practice, and I do not think this proposal does that.

For what it's worth, I agree with Luca that we are ready for a change to
document that service units need to be included now, and I do not think
a change in this area is premature.
I have not (and probably will not get around to) reviewing the specific
text, but I do think it's time for this change now.

(Some of Simon's comments about the security implications of not being
able to depend on systemd for dbus service activation but instead still
needing to support dbus-daemon launching things itself make me think we
should consider even more sweeping changes soon.)

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> It has come to my attention that there is one package in
Luca> Debian using dpkg-divert to mask a systemd configuration file
Luca> (an udev rule).  Speaking as one of the maintainers, both
Luca> upstream and downstream, I find this greatly undesirable for
Luca> several reasons that I will outline later. Hence I would like
Luca> to propose explicitly mentioning that dpkg- divert must not be
Luca> used for systemd configuration files (units, rules, etc), and
Luca> instead the supported workflow (drop-ins, masking, etc) must
Luca> be used, both by packages and administrators.

First, I thought there was already a prohibition about one package
mucking with another package's configuration.
In many cases it sounds like it's already against policy for one package
to change the default systemd or udev configuration--at least for
packages in the archive.
(I am skepticle that amazon-ec2-utils complies with policy in general).


In cases where the change being made is permitted by policy, I think you
have made a compelling case to vastly prefer the native systemd and udev
mechanisms to dpkg-divert.
I don't think that your case is strong enough to forbid dpkg-divert.

As far as I can tell reading your reasoning, dpkg-divert *works fine*.
It just gives surprising results to someone coming from the systemd
universe.

But consider a package that diverts several resources, several of them
systemd and several of them not systemd.
The maintainer might legitimately want to use the same mechanism for all
the overriding/masking  so that systemd resources and non-systemd
resources were handled the same.

There's a real trade off there, and we generally leave those to
maintainers.

So, I'd support policy advice (ENCOURAGED) rather than policy
requirements (MUST) in this case.

I do think that if a maintainer violates this advice without a good
reason, important is a more appropriate bug severity than wishlist, but
unfortunately we don't have a good way to specify that in policy
language.

I would not support policy recommendation language (RECOMMENDED/SHOULD)
because that has a connotation that failing to follow the recommendation
is always a bug, and I don't think that's true here.

--Sam

Re: nocheck (don't run) vs nodoc (don't build)

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Wed 26 Apr 2023 at 04:48PM -06, Sam Hartman wrote:

>> I guess that's consistent with RFC 2119.  And RFC 2119 SHOULD
>> means that the requirement is RECOMMENDED, and an implementation
>> that does not follow the SHOULD needs to have a reason for not
>> following the recommendation.

Sean> Just to note that Debian Policy's definition of these terms is
Sean> not quite the same as the RFC process definitions (I know you
Sean> know this -- just wanted to note that they're not the most
Sean> relevant definitions).

Agreed.
I rated the chance that Simon knew the difference between RFC 2119 and
policy language and spoke with precision at about 80%.  But to reinforce
that I picked a flamboyant usage of RFC 2119 in a manner that did not
fit policy to make sure that it fit Simon's usage, and for Simon to
realize the difference and say "hey no I meant policy language," if on
reading my text  he realized RFC 2119was not what he meant.

Responding to a developer with somewhat less experience I would have
just asked whether they really meant to be using policy language.

Re: nocheck (don't run) vs nodoc (don't build)

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote:
>> Policy 4.9.1 states that (emphases mine): * "[nocheck] says not
>> to *run* any build-time test suite" * "[nodoc] says to skip any
>> *build* steps"
>> 
>> My reading with regards to 'nocheck' was that where tests were
>> available and needed to be built, then they should always be
>> built, just not run.
>> 
>> A typical example might be a C library package that builds those
>> tests and ships them as autopkgtests, maybe even in a dedicated
>> package.
>> 
>> I thought this line of reasoning was sound, but then I remembered
>> the 'nodoc' tag and now I am no longer sure. Maybe I'm taking the
>> 'nocheck' description too literally.

Simon> With RFC 2119 terms, my opinion would be:

Simon> - packages built with the nocheck option SHOULD NOT run tests

Agreed.

Simon> - the nocheck option SHOULD NOT alter the contents of any
Simon> binary package

I agree this is true--possibly even as a MUST--for the nocheck build
profile, but
I think DEB_BUILD_OPTIONS are allowed to modify the contents of binary
packages.
As an example nostrip certainly modifies the size of things, and noopt
can modify the behavior and performance.

My assumption was that if you were specifying the nocheck build option,
you don't want to run tests, possibly because they are flaky and/or you
are trying a build for some local reason even though you know the tests
will fail.

If you actually want to avoid building the tests, use the nocheck build
profile (assuming that can be done without modifying binary packages).

If my reasoning is correct, my interpretation is that nocheck option
can build tests or not, depending on whatever is convenient.

I guess that's consistent with RFC 2119.
And RFC 2119 SHOULD means that the requirement is RECOMMENDED, and an
implementation that does not follow the SHOULD needs to have a reason
for not following the recommendation.

Re: 6.1.3. Multiple binary packages question

[Sam Hartman]

> "Kristian" == Kristian Penno  writes:

Kristian> source package is referenced.  The lyx source package uses
Kristian> some shell commands to move files around in the rules
Kristian> file.  Is this preferred to using debhelper
Kristian> .install files?

No.
If .install files work for you, that's better.

Bug#801065: Documenting how to not fail postinst on service fails to start

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
>> > > > - the service fails to start in the postinst.
>> 
>> This implies that "the service is running" is part of "the
>> service is configured", which is where I disagree.

Wouter> What Steve said is that if

Wouter> - The service fails to start, *AND* - The service was
Wouter> previously running (or this is a new install)

Wouter> *THEN*

I think I disagree with Steve that postinst should fail on a new
install.

I think that failing postinst on a failed restart during upgrade is more
commonly the correct answer than ignoring the issue.
I also agree that it should be RECOMMENDED that if the restart fails
that be flagged to the admin somehow.

But in the case of krb5 and I think a few other services, there is not a
good way to detect at install time *whether* the service is sufficiently
configured to run from a systemd unit.  I could for example include a
ConditionPathExists on the Kerberos database.  That's wrong though
because in an LDAP deployment there will be no such database.

--Sam

Bug#801065: Documenting how to not fail postinst on service fails to start

[Sam Hartman]

The TC bug is 904558.
Busy with day job now.

Bug#801065: Documenting how to not fail postinst on service fails to start

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

Holger> I do agree with that. I'm more against a general
Holger> recommendation, depending on the circumstances, it's the
Holger> right thing to do.

My recollection is this came before the TC, but I'm blanking on the bug
number.
But it seems like the sticking point is the general recommendation.

I'd love to figure out how to do this though and document for other
people (I have a Ubuntu bug open against krb5 that basically boils down
to this issue).

>> Holger, would you support adding a comment to 6.4 explaining how
>> to do it?

Holger> surely.

>> I'd write text but I'm honestly baffled how to accomplish this
>> for systemd units with dh.
 
Holger> :)

Marvin, do you have any clue how to accomplish?

Bug#801065: Documenting how to not fail postinst on service fails to start

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

Holger> I don't think there has been consent on the issue, thus I'm
Holger> tagging it moreinfo.

My reading of the TC and debian-devel discussion was that this was at
least a reasonable thing for maintainers to do,
and whether it should be done depended on the circumstances.

Holger, would you support adding a comment to 6.4 explaining how to do
it?
I'd write text but I'm honestly baffled how to accomplish this for
systemd units with dh.

--Sam

Bug#1029831: debian-policy: Make required packages build-essential

[Sam Hartman]

Ansgar> +--- | The required packages are called build-essential, and
Ansgar> an informational | list can be found in
Ansgar> /usr/share/doc/build-essential/list (which is | contained in
Ansgar> the build-essential package).  +---[ Section 4.2 ]

Ansgar> to something like

Ansgar> +--- | The required packages are called build-essential, and
Ansgar> include packages | with Priority "required" and additional
Ansgar> packages. An informational | list of additional packages can
Ansgar> be found in | /usr/share/doc/build-essential/list (which is
Ansgar> contained in the | build-essential package).  +---

Ansgar> This only documents existing practice as practically all
Ansgar> systems have required packages installed.

I support this change and would second if submitted as a patch.


signature.asc
Description: PGP signature

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:


Santiago> I think you can't really estimate such thing. You seem to
Santiago> imply that we have been allowing packages with missing
Santiago> build-dependencies for a long time, but that's not
Santiago> accurate. The *buildds* have been allowing packages with
Santiago> missing build-dependencies for a long time, but I have
Santiago> been reporting those bugs for a long time as well.

Thanks for the additional information.
You have not changed my mind.
I would prefer to solve this situation by increasing the build essential
set based on what I know today.

I think this is a case where either option is technically reasonable,
and where a fairly rough consensus is appropriate to move forward.
So my hope is that as more people chime in, the policy editors
eventually judge a consensus, but I think it is fine for that consensus
to be more rough than we usually take for policy.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:
Santiago> A minimal build essential set provides and generates
Santiago> useful information that a build essential set which is not
Santiago> so minimal does not provide.

Santiago> For example, some packages have unit tests which depend on
Santiago> the information stored on tzdata. In some cases, changes
Santiago> in tzdata causes those unit tests to fail.

Okay.
I don't find that example particularly compelling.
I absolutely agree with you we've found such bugs, but I think that the
cost of going and adding all the build-depends on
required-but-not-build-essential is not worth what I estimate we'd gain
from having this extra information.

I thin there are a few other reasons we want to keep the build-essential
set small:

* It reduces the number of packages involved in early freeze
* I suspect that there probably are bootstrapping implications.

However, neither of those reasons appear very compelling when applied to
required packages.

I appreciate the work of fixing the packages would be distributed,
although I think a significant portion of it would land on the small
number of people who do archive-wide QA.
Even if it were fully distributed, that work has a real cost.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:


Santiago> As an example, packages tzdata, mount or e2fsprogs are not
Santiago> build-essential and afaik have not been for a long time,
Santiago> but there are still people who believe that they are
Santiago> build-essential for the mere fact that they are
Santiago> priority:required.

Why not just make all required packages build-essential?
I agree we should fix the class of bugs you are talking about, but it
seems like in some cases it might be easier to fix them by declaring
them not buggy.

Re: Idea for Policy expert reviewer list

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> What do people think?  Helpful innovation, or just extra
Russ> bookkeeping that isn't worth the effort?  If people do think
Russ> this is a good idea, I'll bring it up on debian-devel for
Russ> further discussion (and then, if we adopted it, it would be a
Russ> debian-devel-announce post).

I think I'd recommend waiting until you get burned a couple times by not
having the review before implementing something like this.
I've watched the expert review process in the IETF become more involved
over the years, and I think it's important to be careful of  against process
complexity increases.  Mind I think the IETF complexity increases may be
justified: the impact of standards errors today is bigger than it was in
2000.
And it may be that we've reached the point to start down that road in
Debian.
But I'd prefer to have concrete things we're accomplishing with a change
like this.  They might look like:

* I'm an expert in foo area, but debian-policy is too much traffic, and
  I'm struggling to keep up

or

* We didn't get enough review and we made a mistake with the bar
  change.  We have experts who would have done the review if asked but
  do not read debian-policy.

--Sam

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

[Sam Hartman]

>>>>> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:

>> I think that hard links in a source package are fine provided
>> that breaking the hard links would not either break the build or
>> provide an unreasonable space multiplier.

Russ> I agree with you that those would be undesirable properties,
Russ> but are they likely and important enough to have it be worth
Russ> retaining a section talking about this, as opposed to using
Russ> the "not every bug is a Policy violation" rule?  We do pay a
Russ> (small) complexity cost for each additional requirement we put
Russ> in Policy, so I'm tempted to just drop this entirely and bank
Russ> the complexity reduction.

You have me sold on not likely enough to matter.
I do think that having the build break (or worse produce bad results) on
hard link breaking would be a really important problem because of how
much it violates the principle of least surprise, but I agree that it is
unlikely enough that it need not be covered in policy.

--Sam

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


Bill> What if the user change their CPU afterward ?  This should
Bill> probably be tested at boot time instead.

There was a long thread on debian-devel about the potential issues with
isa-support:
https://lists.debian.org/yj5dazgacdgtp...@angband.pl

So, what you say is true, but isa-support has an existing interface it
needs to stay consistent with that involves checking at install time.
I think we're all agreed that we want to find alternatives to that
interface, but the policy question is about what ways of implementing
the existing interface are consistent with policy.

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

roucaries> No the problem is not probing the cpu/cpuinfo...

Well, if the CPU info could be probed from shell, I'd argue that's
better than unpacking a binary.

roucaries> The problem is the base64 encoded binary.

Why is this bad.
I agree that it is esthetically displeasing, but *in this instance*, why
is it harmful?

roucaries> I ma solving this by pre-depends on a binary package and
roucaries> run the binary from the preinstalled package.

I would have been less caustic in my reply than Adam, but made the same
point.
Having multiple packages is more complex, especially in a situation
where the binary in question  is only used by the preinst.

It may be there are concerns I'm not seeing that make the current
arrangement worse than taht.
But let's actually articulate them.

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

> "Bastien" == Bastien Roucariès  writes:
Bastien> I will like to stress that this kind of stuff is bad:
Bastien> 
https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec-
Bastien> support.preinst.in#L10

How would you do better in that instance?
I think everyone knows it's bad, but I'm guessing that the maintainer
didn't have a better approach for detecting whether the referenced
instructions worked on the installed system.

I'm assuming that if feature tests in /proc/cpuinfo were sufficient they
would have been used.

--Sam

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

Holger> On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
>> > Even if that consensus does not exist, there is probably
>> consensus > that native packages are a poor match for large
>> packages (because of > the inefficiency of making small updates
>> to the packaging of native > packages), Do you mean large
>> packages with a separate upstream existence, or large packages in
>> general?  I don't think there's such a consensus for large
>> packages in general: if Debian is the canonical place for a
>> particular package to be released (e.g., as is true for dpkg),
>> then it doesn't seem like it would be worth the overhead of
>> making two releases, one upstream and one for packaging, whenever
>> updating that package.
 
Holger> speaking as the debian-edu-artwork maintainer, which at one
Holger> point in time was a >50mb sized native package: it's pretty
Holger> annoying to upload 50 or more megabytes for a 2 byte fix of
Holger> a maintainer script.

I'd much rather upload  a 50M package regularly than deal with the vcs
complexity of separate maintainer and upstream releases in a lot of
cases.
10 years ago sure, that would have been annoying for me, but these days
with modern networks 50M is not a big deal.

Granted not everyone has a fast network.

If there is a consensus that the upstream source split is important for
large packages, it is fairly rough.
I'd definitely like to call that consensus into question and suggest
that it's unclear whether it exists.
It may; my opinion on this issue is definitiely on one side, and that
would make me a poor choice to judge the consensus here.
However, I don't want us to move forward assuming that consensus exists
without actually exploring it.

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:


Sean> On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote:

>> Sean Whitton  (2021-08-12):
>>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote:
>>> 
>>> >
>>> > So, it seems fairly obvious to me that Standards-Version is
>>> important > for packages that produce both debs and udebs.  >
>>> I'm assuming the focus of our discussion then is on source
>>> packages that > only produce udebs.  > Have I got that right?
>>> >
>>> > By definition, most of the policy that affects binary packages
>>> does not > inherently apply to udebs.  As I understand it,
>>> that's kind of the point > of udebs.
>>> 
>>> Would you agree with this?  You're only asking to stop seeing
>>> warnings about S-V for source packages which produce only udebs?
>> 
>> Yes, that looks good to me: source packages (also) producing debs
>> would deserve a rightful nag.

Sean> I believe that we failed to consider udebs when we made the
Sean> change which made S-V mandatory.  I propose we remove the
Sean> requirement for S-V in udebs and source packages producing
Sean> only udebs, until and unless someone provides a positive
Sean> argument why S-V ought to be mandatory in these cases too.

I thought I provided such an argument.
(you trimmed that part of my message when replying).
My argument was roughly that  things like build systems, use of dh,
debian/rules interfaces etc might well need to apply to source packages
producing only udebs.
I think the issues are kind of complex,  and I agree with you that we
didn't consider udebs properly.

I do think though that you ignored the meat of my message and I think it
is worth a bit more consideration than that.

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Sam Hartman]

> "Cyril" == Cyril Brulebois  writes:

Cyril> Hi, Felix Lechner  (2021-07-26):

Cyril> cc-ing debian-policy@ for some possible feedback.

Cyril> I'm not sure why we should be spending time tracking down
Cyril> Policy changes in (source for) udeb packages… so adding then
Cyril> updating this field to all our packages doesn't seem to do us
Cyril> any good.

So, it seems fairly obvious to me that Standards-Version is important
for packages that produce both debs and udebs.
I'm assuming the focus of our discussion then is on source packages that
only produce udebs.
Have I got that right?

By definition, most of the policy that affects binary packages does not
inherently apply to udebs.  As I understand it, that's kind of the point
of udebs.

But there's a lot of policy that applies to source packages.  AS an
example, the description of the debian/rules interface, rules about how
builds work, rules about what builds can and cannot do, rules about how
to influence builds (compiler options and the like).

So, in my mind, the biggest question is should all those aspects of
policy apply to packages producing only udebs.

I don't have an answer to that, but I do have some thoughts:

1) I realize i don't entirely know why udebs are udebs not debs.
I think it will help us in the discussion if we have a clear answer to
that question.

2) i suspect that we have not explicitly been considering source
packages that make only udebs when we've been thinking about policy
changes.  So it's likely that there are some bugs in this regard.

3) I think  many things such as  the debian/rules interface, how to
specify compiler options, and the like are good ideas for dscs only
building udebs.
I'd say that there are significant chunks of policy it would be a great
idea for d-i packages to comply with.

For me, I'd need to know more about 1 in order to have an opinion on
whether there should be an obligation to comply with these aspects of
policy.  

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:

>> To be clear, my understanding of the advocacy of using non-native
>> packages is primarily about their impact on *Debian* workflows
>> (being able to base multiple packages on the same tarball, not
>> introducing confusion between upstream version numbers and Debian
>> version numbers and thus making it easier for other people in
>> Debian to track the package to an upstream version, triggering
>> various package checks that ignore native packages but care about
>> non-native packages such as uscan, etc.).

Sean> I believe that we need to distinguish between version numbers
Sean> without Debian revisions and native source package formats.
Sean> At one point an experienced contributor convinced me that
Sean> there are cases where it is good to use a version number with
Sean> a Debian revision but a native source package format.

I agree with this advice.
Does the current tooling support it?

Sean> Perhaps we can already write something useful in Policy about
Sean> packages which don't use Debian revisions, even though there
Sean> is a lack of consensus about source package formats?
Sean> Something like: you should always include a Debian revision
Sean> unless the package has a release process which is tightly
Sean> coupled with making uploads to the Debian archive (and we
Sean> would not want to include the converse, that having such a
Sean> tight coupling implies you shouldn't include a Debian
Sean> revision).

Assuming that dpkg-source supports this, I would generally support the
advice you're working toward and would be likely to second specific
text.

Bug#944920: Revise terminology used to specify requirements

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Russ Allbery  writes:
>> In attempting to revise recent GRs to use the same terminology as
>> Policy, I got frustrated again by the lack of precision of our
>> current language.  This is an attempt to make a minor
>> improvement.  It doesn't go all the way to using all-caps terms
>> the way that RFC 2119 does; I think that might be an improvement,
>> but it was a larger change than I wanted to tackle.

Russ> It's been over a year since the last activity on this bug so
Russ> although there were enough seconds for a revised form of this
Russ> patch, I'm reposting it to remind people where the discussion
Russ> was and as a quick double-check that I didn't mess up the
Russ> rebase.

Hi.
I reconfirm my second after reviewing the patch.


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Hi Sam,

Russ> Thanks for the review!  There's now a newer version of this
Russ> diff adjusted for a flaw that Simon pointed out.  It's
Russ> sufficiently different from the original diff that I don't
Russ> want to count seconds for the original as seconds for it.
Russ> It's at:

Russ> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280

Aargh, sorry.
I read Simon's message, and then read your earlier patch in the wrong
order, and thought, wow Russ managed to come up with a way to address
Simon's issue that was shorter than I thought.
(Not realizing that I was responding to a message before you had
addressed it).

I'm happy to second the newer patch in #280 although I have one
non-blocking comment.

+- ``upstream_version`` components in native packages ending in
``+debNuX``
+  indicate a stable update.  This is a version of the package uploaded
+  directly to a stable release, and the version is chosen to sort
before
+  any later version of the package uploaded to Debian's unstable or a
+  later stable distribution.  ``N`` is the major version number of the
+  Debian stable release to which the package was uploaded, and ``X`` is
a
+  number, starting at 1, that is increased for each stable upload of
this
+  package.
+


Because this comes before [+~]debXuN in the Debian revision, it's easy
for a reader to treat this as a common case on first reading.
I think it's much more common for us to have the stable update noted in
a Debian revision than in the upstream revision, and we should say this.


I hugely confused myself by missing the word "native" in the above  and
was starting to think about why we'd ever mark a stable update in the
upstream version of a non-native package.
Your text does in fact include native, but this illustrates how even for
a experienced packager, having the uncommon case first can  lead to
confusion.

--Sam


signature.asc
Description: PGP signature

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

I do not support advising against using native packages with our current
tooling.

My issue is that for some work flows  generating and keeping up with the
upstream tarballs significantly increases the frustration of packaging
and and brings doing a package update across a pain threshhold that
psychologically matters.
The idea is that if I can accomplish a task in a minute or two without
much frustration, I'll do it more and be happier doing it.

If the task takes twice as long, especially when I can't see the value
in the steps, resentment builds up, happiness decreases, and the task is
done less often.

Being able to update packages frequently without frustration is more
important to me than the legitimate concerns raised about native
packages.
I was actually surprised how many legitimate things to think about we
came up with while discussing native packages during my DPL term.
(There's a pointer from the consensus summary I wrote up to d-d-a.)

But at least for me, when I'm trying to closely track a fast moving
upstream  from a git repo, native packages are just easier.
Generating new upstream tarballs for each upstream change, trying to
keep track of when I needed to do that,  and keeping track of all the
upstream tarballs crosses a frustration threshhold for me.

Various suggestions were made during previous discussions to make
workflows easier.
Unfortunately, these suggestions were generally made while dismissing
the needs of people favoring native packages.
I'll admit that I was frustrated when people were dismissing my concerns
enough that   it was hard to engage with the suggestions.
It's possible there are better work flows I don't know about, but I
think there are still gaps.

I'd propose the following way forward:

1) Capture the discussion thread we had during my DPL term and the
things to think about that were brought up in the native packages part
of that discussion.
I'm not sure policy is the right place for those; I think some of those
might better belong in a wiki page or dev ref.

2) Figure out  what the work flow gaps are that cause people to find
native packages easier to deal with.
I suspect we'll find that something in our git workflows is not great
especially for closely tracking upstream git and especially when
upstream itself doesn't make releases.

3) Fix these work flow gaps.

4) Then add advice to policy.



signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated diff that documents the most
Russ> well-understood version conventions in the Debian archive.
Russ> More could certainly be added; this is just a first start that
Russ> addresses this specific bug.

Russ> This revised patch is less aggressive about defining native
Russ> packages to only mean packages with no existence external to
Russ> Debian.  I also found that we never define upstream, which
Russ> seems like a critical concept, so I added a definition to the
Russ> Definitions section.
second.


signature.asc
Description: PGP signature

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> Let us be honest with ourselves: what matter for most purpose
Bill> is the position of the ftp-master team that processes the NEW
Bill> queue.  What policy says is secondary.

I absolutely agree we should coordinate appropriately with the ftp team.

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> That said, I tend to be hyper-conservative and nit-picky about
Russ> things like this, accurately representing copyright years
Russ> isn't in my top thousand things I want people to work on in
Russ> Debian, and I'm highly dubious that it will ever matter or
Russ> anyone will ever care.  So I'm very open to being told I'm
Russ> being much too cautious.

My rationale is that debian/copyright is a summary, it's not the license
text in the files.
I absolutely agree we shouldn't go change people's actual copyright
notices in the files.

And, I'm fairly convinced that it can never hurt us.  I mean if someone
came along and actually bothered to send us a legal letter, or even a
strongly worded bug report as a copyright holder, we'd go  use their
preferred notice.
What sort of damage are they going to be able to show because we listed
2009-2020 instead of 2009, 2012, 2019-2020.

As a copyright holder I'd probably be more annoyed at the hyphen instead
of the n-dash rather than the notice.  But that's  just me.

But I totally understand we're well into bikeshedding here.

On the compromise front, how would people feel about leaving the gap
years question ambiguous in policy?
That is, we clearly agree you can combine years across files, our
question is whether you can insert years that appear in no file.
Could we just sidestep the issue and leave that ambiguous?

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

Here's my take on the discussion so far.
And I want to stress that I am not a policy editor, and to the extent
that they read the discusssion differently than I do, their reading
controls.

* Russ and I would be willing to accept either outcome--either you can
  collapse years or you cannot.

* Holder, you and I would prefer that you be able to collapse years.

* Sean would prefer that you not be able to collapse years.  He hasn't
  said whether his objection is strong enough to try and block
  consensus.

* I think there is a strong consensus that we want to make a change
  along the lines of one of your patches.

* I don't think anyone in the discussion so far would object to your
  second patch.  However, a majority of the participants might prefer
  your first patch.  Sean might object to that, and Russ might
  potentially think we haven't yet gotten enough showing of support to
  go that direction.

This is one of those awkward situations in consensus decision making
where you have to decide whether you're going to take the option
everyone can live with or do a bit more work and possibly get  an answer
that the community overall supports (even though some people do not).
What we should definitely avoid doing is losing energy and making no
change at all.

--Sam

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Sam Hartman]

> "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 help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found the policy text in this area a bit opaque.
I'd like to understand what we'd be giving up if we adopt your proposal.

Is this facility not used simply because everyone reads it and like me
goes "huh what does that really mean," and never gets around to thinking
it through?
Or is it an extension point we actually don't need?

Also, how much of the complexity cost you are concerned about has
already been paid and how much of it is ongoing?
Ignore for the moment maintenance in packages like dpkg-dev and sbuild.
I'm basically asking how many new tools over time are likely to need to
care about this complexity if we keep it.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

I'd like to see people chime in who have not participated in the
discussion yet.
I prefer your original text but we'd need to get support for it.
It sounds like we're fairly evenly split among the current participants
in the issue.

--Sam

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Marc Haber  writes:
Russ> The years are an annoying bit of pedantry.  The short version
Russ> is that US copyright law requires a year in the notice, and
Russ> that year is supposed to represent a year in which a
Russ> copyrightable change was "published."  The FSF a long time
Russ> back got legal counsel here and published guidance in the GNU
Russ> Maintainer Guidelines, and since I've never wanted to
Russ> reproduce that work, I tend to just follow them.  They say:

The years matter because at least under  US law, the most recent year in
which a change happened affects how long copyright potentially lasts.

fsf> Don’t delete old year numbers, though; they are
fsf> significant since they indicate when older versions might
fsf> theoretically go into the public domain, if the movie
fsf> companies don’t continue buying laws to further extend
fsf> copyright. If you copy a file into the package from some other
fsf> program, keep the copyright years that come with the file.

I appreciate that the FSF cares about old years and things going into
public domain.  I think that we should value being able to coalesce
years more than we value that pedantry.  I think the FSF has adequately
explained the legal rationale for their view, I think their legal
reasoning is sound (so we can rely on it), and I think it doesn't apply
to our needs (so we can do something else).

I don't think we should go so far as to only list the most recent year,
but I do think we should collapse things down to a range in
debian/copyright.

I always assumed from the current wording we could do so
and it's a significant surprise to me that you are arguing we cannot.

Obviously we should leave the notices in source files alone.


signature.asc
Description: PGP signature

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

>> I'd propose that as a first step we change that to
>> 
>> Packages are not required to declare any dependencies they have
>> on other packages which are marked Essential (see below), but are
>> permitted to do so even if they do not depend on a particular
>> version of that package.[4]

Bill> This is very dangerous with respect to upgrade between stable
Bill> releases.  The issue is at the time a package is made for a
Bill> stable release, the state of Debian and Essential: yes
Bill> packages is not known. It is unrealistic to expect Debian to
Bill> plan so far in advance.  Requiring changes to Essential
Bill> packages to take into account spurious dependencies is too
Bill> fragile.

I'm sorry, but I consider myself reasonably knowledgable about package
dependencies and Debian--not admittedly as knowledgable as you, but
knowledgable enough that I ought to be able to follow this discussion.
And after spending a couple minutes thinking about the above I don't
understand what you are getting at.

So, please explain in enough detail that we are able to understand and
evaluate your concern.

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

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


Bill> I am pretty sure we were concerned about source packages being
Bill> unpackable on non Debian systems, though.

And I think we probably still are.  I was trying to capture the concerns
there in the part of my message you trimmed.


My rationale is that I don't think we want to work around an upstream
build system or repack sources just because it has hard links.  On the
other hand I also don't think we want to depend on hard links being
preserved.

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

[Sam Hartman]

> "Giacomo" == Giacomo Catenazzi  writes:

Giacomo> The rationale was probably similar so symlinks: they may
Giacomo> fail across different filesystems, and we supported to have
Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
Giacomo> /home /tmp /boot etc on different file systems. Now we are
Giacomo> more strict on where we can split filesystems (and disk are
Giacomo> larger, and LVM simplified much of filesystem handling).

But I think even in 1996, we anticipated a single source package
(*source package*) being unpacked on a single filesystem.
Perhaps we were worried about filesystems like umsdos?


I think that hard links in a source package are fine provided that
breaking the hard links would not either break the build or provide an
unreasonable space multiplier.

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

> "Josh" == Josh Triplett  writes:

Josh> Long-term, I'd like to see that happen. But I'm a huge fan of
Josh> incremental steps; defining the problem as "eliminate
Josh> Essential" makes it both difficult enough and controversial
Josh> enough to make it unlikely to happen at all. Right now, the
Josh> first step is "let's not let the problem get any worse, and
Josh> let's ensure that any new package that might have otherwise
Josh> used Essential must instead get packages to add a dependency".

Josh, my current reading is that there is not support for even the first
step.
I believe Guillem and I have disagreed, and I haven't noticed support
from anyone other than you.

Is there support I'm failing to remember?

I would not attempt to summarize Guillem's concerns.
My concerns are roughly that I think

1) debian-devel consensus is an
adequate block for things getting worse unless there is a good reason

2) I am not convinced that we would (or should) decline to use this
particular hammer if it really is the best tool we have available for a
bind we find ourselves in; nor do I think policy would actually bar us
if we had necessity

3) The benefit I perceive in spending more time trying to figure out
whether I could be convinced that there are no circumstances under which
I'd support a new essential package is less than  what I think we'd get
out of it , so I'd rather not spend the time.

In the interest of being constructive:

A) I do support reducing the essential set over time

B) I would support better education of the community about why we should
be hesitant to support essential: yes on debian-devel

C) I'd support non-normative documentation that we don't expect to
approve new essential packages in the future in policy.


--Sam

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Sam Hartman]

I'm ignoring the case where capabilities are dropped in my analysis.

I've long valued that Debian does not mark file paths as readonly and
would not support this change.
I've worked on other Unix distributions that did this, and I found that
it decreased the  quality of life of the sysadmin enough that I just
enjoyed being on Debian better and that this decision was one that
contributed.

Yes, root can write to anything.
But several tools make it harder to write to things as root  if they are
without write permission.

I think the value of stability and  making it easy for the sysadmins is
more important than this change absent cases where capabilities are
dropped.

I haven't thought about the capability dropped case enough.  If that
ends up being our rationale, I could hold my nose and go off in my own
corner and grow a beard and grumble in my old age, talking about how
great things used to be back in the day.

In other cases I'm strongly opposed to this change.

--Sam


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Sam Hartman]

I strongly agree with Ian in this matter.

I think there are at least two cases where this issue comes up and is
importand, and where using a debian revision without separate upstream
tarballs is the right approach:

1) small packages currently maintained by the upstream maintainer where
debian revision is incremented for packaging only changes and upstream
revision is incremented for upstream versions

and

2) Cases typically outside the Debian archive where a git tree is being
built as a Debian package especially as part of a CI system and where
the effort of tracking upstream tarballs is undesired.

2) is more of an issue for lintian than it is for debian-policy.

While I feel strongly about this, and believe that  I adequately
explained my position years ago on debian-devel when dpkg first started
rejecting packages with debian revisions and 3.0(native) format,
I don't have the emotional energy for a discussion of this.
The way I was treated by the dpkg maintainer back then caused me to stop
working on Debian for months and seriously consider moving on to other
things.
I just don't have the emotional bandwidth to deal with a discussion
where well-considered arguments will be ignored and/or dismissed with
little consideration.

So, +1 on this, but don't expect me to be able to participate much in
the discussion.


signature.asc
Description: PGP signature

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sam Hartman]

No, I missed this.
We're on the same page.

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> But is it an actual problem ?  Do we see packages marked
Bill> Essential: yes by mistake ?

I think Josh's analysis brought up some important points for me that I
did not consider before and that need to be considered making decisions
in the future.
I think capturing that analysis in a pointer from policy or in policy is
important to me.

Bill> Each time we make policy longer we dilute the content.


Obviously, in the limit this is true.
I think that capturing rationale for things that have good rationale and
that could affect the project if not properly considered is worth doing
even though it makes policy longer.

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

I concur with the comments raised so far.

I think it would be great to do a better job of outlining the problems
with essential packages in debian-policy.
I don't understand why we would tie our hands though.
A consensus of debian-devel seems adequate to consider those issues and
evaluate them.
If after making that consideration we decide to create a new essential
package, we're going to do that policy not withstanding.

I would support a statement in policy that as of the time of writing we
do not anticipate ever creating a new essential package.  That would
help people considering proposing making an essential package know they
are probably looking at things the wrong way.

--Sam

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sam Hartman]

I think there is another use of debian/copyright beyond just documenting
what ends up in the binaries.
I think that if I read debian/copyright in a source package, I should
expect to understand the licenses I need to comply with when dealing
with the source package.

So for example  if the package requires GPL-3 code during its build, and
by policy I don't want to deal with GPL-3 I should know I have a problem
only from reading debian/copyright.


So I think you need to talk about more than just binaries.

--Sam

Bug#950994: Discourage package in contrib to install the real program via another package manager

[Sam Hartman]

I'll note there's another case where this could be valuable.
If there is an installer in contrib, you can express dependencies on the
package being available in Debian.
Depending on how that installer works, you may not be able to express
dependencies on the installed version in Debian.

I think that unless there is a reason for such an installer, they should
be discouraged.
But I can see good reasons.
I'm not really sure that policy is the best place for this sort of
discouragement though.

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

[Sam Hartman]

> "Sean" == Sean Whitton  writes:


Sean> Encouragement is still normative, so if we're going to encourage it,
Sean> it would be better to say /when/ it's encouraged and when it's not.

I think it should be encouraged when there is not a good reason to do
otherwise.
I think the most common reason not to do otherwise (the only reason I
can think of that is likely to be common) is to preserve upstream's
service unit name.

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

[Sam Hartman]

> "Russ" == Russ Allbery  writes:


Russ> Ah, hm, yes, that's a good point that I didn't notice when copying 
that
Russ> Policy recommendation over from the recommendations on init scripts.

Russ> The obvious concern here is that multiple packages could use the same
Russ> service name, and making the service name match the package name 
reduces
Russ> that risk considerably.  But I think I agree that staying consistent 
with
Russ> upstream is more important than adopting that policy in a strong 
sense.

Russ> Do you have a suggestion for alternative wording?  I think we still 
need
Russ> to say something about matching the name of the init script if any, 
and if
Russ> upstream doesn't provide a service unit, it seems reasonable to use 
the
Russ> name of the package (but maybe that should be encouraged rather than
Russ> recommended?).

I think should -> encouraged would go a lot of the way.
Especially with a sentence along the lines of
"Often, preserving an upstream's choice of service unit name is more
important than having a service unit match a package's name."

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Sam Hartman]

> "Philipp" == Philipp Kern  writes:

Philipp> I'm told it was broken by the upgrade of Apache - apparently it 
can no
Philipp> longer do per path client certificate authentication. There is a
Philipp> pending RT ticket from DSA to fix that but I don't think there is
Philipp> anything I can do at the moment - except turn on SSO for the whole
Philipp> vhost. Maybe that could even be a workaround for now and we could
Philipp> check if someone is annoyed by that. :)

TLS dropped the facilities necessary to do that.
Ultimately you'll need a vhost for stuff that requires client certs and
other vhosts that do not.
The user experience of having a site request client certs when you don't
have one to give is really bad in some browsers.

Client certs really kind of are the unloved step child of web
authentication.

Bug#948115: Revise init script Policy based on GR result

[Sam Hartman]

Russ said off-list he was ready for seconds.
I second his patch with the status being encouraged rather than
recommended change.
In seconding, my primary review criteria was whether I thought the
change accurately reflected what the GR conclusion was.

--Sam


signature.asc
Description: PGP signature

Re: Guidance on solving the username namespacing problem

[Sam Hartman]

> "Philipp" == Philipp Kern  writes:

Philipp> I tried to raise this issue in [2] a year ago, but I think I don't 
know
Philipp> how to even start drafting a policy snippet about this. Would it be
Philipp> sufficient to just mandate "In order to avoid collisions with 
accounts
Philipp> created by the system administrator, usernames created by packages
Philipp> should start with an underscore." (assuming we could get a rough
Philipp> consensus for something like that) in 9.2.1 for now? Or is this
Philipp> effectively infeasible until we come up with a good migration 
story?

I think you could certainly do  usernames created by packages are
encouraged to start with an underscore.

Encouraged being the new normative word meaning that maintainers ought
to do x unless they have a reason (like an existing username) to do
something else.

You could also do something more complex like

When maintainers choose a new hard-coded or dynamically generated username
for packages to use, they should start this username with an underscore.

Intent there is to capture making it a bug to do something else for new
usernames without making requirements for existing names.

Note that in cases like debconf, I don't think we want an underscore
prepended to what the user chooses, although I think defaulting to
something with a leading underscore would be fine.

Bug#948115: Revise init script Policy based on GR result

[Sam Hartman]

I've reviewed your patch.
It looks good.

One minor suggestion:

+The ``start``, ``stop``, ``restart``, and ``force-reload`` options should
+be supported by all init scripts. Supporting ``status`` is recommended but
+not required. The ``reload`` and ``try-restart`` options are optional.

How about supporting status is encouraged.
At this point in the game, do we really want people opening bugs because
an init script doesn't support status?

Besides that, LGTM.

Bug#944920: Revise terminology used to specify requirements

[Sam Hartman]

Russ, I've reviewed your new patch.

I haven't been participating in this discussion before, but I think it
is fair to say that I have significant experience with these sorts of
normative language discussions and Debian policy in general.

I agree with all your changes (with one question below).
My review was insufficient to catch changes you should hav made but did
not.

One question:

+The Release Team may, at their discretion, downgrade a Policy requirement
+to a Policy recommendation for a given release of the Debian distribution.
+This may be done for only a specific package or for the archive as a
+whole. This provision is intended to provide flexibility to balance the
+quality standards of the distribution against the release schedule and the
+importance of making a stable release.

I wonder if that should be can (or is permitted) rather than may.
Saying it is optional implies that the policy is not making a
recommendation on whether they should make such changes.
I guess that's true, but either:

1) it's in scope for the policy to permit this.  In which case may is
too weak.

2) It's out of scope, in which you should not use normative language at
all.

Some will argue that it's inherently out of scope for you to make that
recommendation because of separation of concerns between the policy
editors and release team.
I think it would be inappropriate for the policy editors to update what
policy says about what the release team can do without sign-off from the
release team  (or change in the delegation text).  For example it would
clearly be inappropriate for the policy editors to change "is permitted"
to "must not" in the above without the release team agreeing.
But I think whether policy makes normative documentation in this space
should be decided based on what is best for the project rather than on
who all would have to approve such changes.

That said, can is simpler.

Regardless of may, can, or is permitted, I second your patch.


signature.asc
Description: PGP signature

Re: Proposal for next steps for systemd-related policy

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello Russ,
Sean> On Sun 29 Dec 2019 at 10:47am -08, Russ Allbery wrote:

>> This is a tentative proposal for next steps from a Policy standpoint 
given
>> the result of .  I thought it
>> might be helpful to lay out a possible way to sequence the work.

Sean> Thank you for writing this.

>> 1. Downgrade the requirement to include an init script in a package with 
a
>> systemd unit to "encouraged."  This is the direct outcome of the GR, so
>> I think we should make this change before the next normative upload,
>> since there's no point in Policy being inconsistent with the GR result.
>> 
>> I think there's some discussion to be had here about whether the
>> correct level is "encouraged" or "optional."  I'd also like to revise
>> and merge my change that adds "encouraged" first, although if we decide
>> "optional" is correct, that sequencing is, well, optional.

Sean> Under the new description of these words in #944920, I think we would
Sean> have to use 'encouraged'.  That new text says that 'optional' is meant
Sean> to be used purely for clarificatory purposes, but incorporating the
Sean> result of the GR into Policy would not be a matter of clarifying
Sean> something else said in Policy, so far as I can tell.

Sean> I think it's useful for 'optional' to be reserved for its 
clarificatory
Sean> role.

>> 3. Start a discussion on debian-devel to see if we can come up with some
>> idea for how to declare dependencies on availability of system
>> services.
>> 
>> My thought process here is that while the GR permits packages to start
>> using systemd facilities directly, doing that without somehow declaring
>> that requirement in package metadata seems likely to cause bugs and
>> upgrade issues, so we should try to provide some better facilities.  I
>> think there's an obvious gap here where we need a mechanism to declare
>> a dependency on a system facility (as distinct from a package that may

I haven't been following the consensus around making service units more
recommended.
Ignoring that discussion, but folding in the GR:

Maintainers are recommended to install at least one of a service unit or
init script.
Maintainers are encouraged to install an service unit and may install an
init script.

But if you've gotten to a point where service units are recommended all
the time (no service unit but an init script is a bug) then: Maintainers
are recommended to install a service unit.  If maintainers do not
install a service unit, they are encouraged to install an init script;
in other situations installing an init script is optional.

That at least is my take on what Proposal B implies in the new policy
terminology.
BTW, I like the new terms!  Great work

Bug#930666: Please document consensus on use of dh sequencer

[Sam Hartman]

My second still applies to the following diff; I agree this is
consistent with the discussion so far.

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index ee9270d..93beb4a 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -259,13 +259,33 @@ files, sockets or setuid or setgid files.. [#]_
 Main building script: ``debian/rules``
 --
 
-This file must be an executable makefile, and contains the
-package-specific recipes for compiling the package and building binary
-package(s) from the source.
-
-It must start with the line ``#!/usr/bin/make -f``, so that it can be
-invoked by saying its name rather than invoking ``make`` explicitly.
-That is, invoking either of ``make -f debian/rules args...`` or
``./debian/rules args...`` must result in identical behavior.
+This file must be an executable makefile.  It contains the
+package-specific recipes for compiling the source (if required) and
+constructing one or more binary packages.
+
+``debian/rules`` must start with the line ``#!/usr/bin/make -f``, so that
+it can be invoked by saying its name rather than invoking ``make``
+explicitly.  That is, invoking either of ``make -f debian/rules args...``
+or ``./debian/rules args...`` must result in identical behavior.
+
+The recommended way to implement the build process of a Debian package, in
+the absence of a good reason to use a different approach, is the ``dh``
+tool.  This includes the contents of the ``debian/rules`` building script.
+``dh`` is the most common packaging helper tool in Debian.  Using it will
+usually save effort in complying with the rules in this document, because
+``dh`` will automatically implement many of them without requiring
+explicit instructions.
+
+There are sometimes good reasons to use a different approach.  For
+example, the standard tools for packaging software written in some
+languages may use another tool; some rarer packaging patterns, such as
+multiple builds of the same software with different options, are easier to
+express with other tools; and a packager working on a different packaging
+helper might want to use their tool.  The recommendation to use ``dh``
+does not always apply, and use of ``dh`` is not required.
+
+For more information about how to use ``dh``, see the documentation in the
+debhelper package, most notably the dh(1) manual page.
 
 The following targets are required and must be implemented by
 ``debian/rules``: ``clean``, ``binary``, ``binary-arch``,



signature.asc
Description: PGP signature

Bug#930666: Please document consensus on use of dh sequencer

[Sam Hartman]

I believe that both Russ's text and  Sean's revised text capture the
project level discussions.

I also believe that given those discussions the issues are well
understood enough for us to move forward relatively quickly if new
issues are not raised here.  I believe that Russ has adequately
responded to the issue that Bill raised.

As such, at least under my understanding of the policy process, I think
I've reached the necessary conclusions to second a proposal on this bug.
So, I second Sean's revisions to Russ's proposed wording.

--Sam


signature.asc
Description: PGP signature

Bug#930666: Please document consensus on use of dh sequencer

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Let me try to express what I think the problem is.  What the
Sean> first sentence says, given the equivalence of RECOMMENDED and
Sean> SHOULD noted above, is "you should use dh unless there is a
Sean> reason not to use dh".

Sean> However, any SHOULD requirement in Policy implicitly has that
Sean> structure: "you should X unless there is reason not to X".


That's not how I read policy at all.
>In the normative part of this manual, the words *must*, *should* and
>*may*, and the adjectives *required*, *recommended* and *optional*,
>are used to distinguish the significance of the various guidelines in
>this policy document. Packages that do not conform to the guidelines
>denoted by *must* (or *required*) will generally not be considered
>acceptable for the Debian distribution. Non-conformance with
>guidelines denoted by *should* (or *recommended*) will generally be
>considered a bug, but will not necessarily render a package unsuitable


No where in the above text do I see that if there is a good reason not
to do x, that x is not a non-RC bug in your package.
This is the key difference between how policy uses those terms and RFC
2119.

So, I think Russ is correct that what we're saying is that you should do
x unless there is an adequate reason not to.
If recommended in policy language actually meant that, we could say dh
is recommended, spend a bit of text giving examples of reasons why it
doesn't apply and be done.

I'd be in favor of changing policy so that should meant should x unless
there is a good reason not to do x, but that is a much much bigger
change.

Bug#930666: Please document consensus on use of dh sequencer

[Sam Hartman]

package: debian-policy

Dear policy team:

I just published a consensus call on a discussion we had to canvas the
project on the use of Debhelper's dh sequencer.
https://lists.debian.org/msgid-search/tslmuif7pwy@suchdamage.org

I'd like to ask the policy editors to facilitate using the normal
process to document this consensus in policy.

My understanding is that the editors already have some ideas about how
that might work.

Obviously I'm available to help as desired.

In the interest of setting expectations, if this issue is still open in
December, I plan to check in and see whether I think the approach of going
through the normal policy process still makes sense.



signature.asc
Description: PGP signature

Re: Thinking about Delegating Decisions about Policy

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:

Sean> Hello Sam,
Sean> On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote:

>> What are people's thoughts about this?
>> 
>> Will this approach work for the TC and policy editors?

Sean> I think that the concrete suggestion you're making is that
Sean> when a question that comes before the T.C. is something that
Sean> could be solved by patching the Policy Manual, the T.C. should
Sean> respond to the question by opening a bug against the Policy
Sean> Manual, and suspending the T.C. bug until it becomes clear
Sean> whether or not that debian-policy bug is going to reach
Sean> consensus?

That's an over simplification, but it's approximately correct.

I'm saying that this is an approach the TC could use, rather than an
approach that the TC should use.  I'd hope the TC would evaluate whether
they thought it would be productive rather than blindly using any
procedure.
Similarly, I'm hoping that in such a case individual TC members might
consider being involved in the policy process where appropriate.

--Sam

Re: Managing Frozen text when the TC Decides Policy

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:

Sean> Hello Sam,
Sean> On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote:

>> I agree that it would generally be unfortunate if we had policy
>> text that could not be changed by the policy process.  I can see
>> rare situations where it might happen: we might have legal advice
>> requiring specific text be included in packages under certain
>> circumstances.  And in such a situation it might well be that
>> we'd expect the policy editors to go back and check with lawyers
>> before changing that frozen text.

Sean> We actually already have this situation with several bits of
Sean> text that the Policy Editors don't consider ourselves able to
Sean> edit without ftpmaster approval.  See, for example, #904729
Sean> and #912581.

These cases look like cases where you have frozen requirements not
frozen text.  That is, it doesn't look like you'd have any trouble
rewording the requirements, but that when you are documenting archive
acceptance criteria, you must be consistent with ftpmaster.

That makes a lot of sense.

>> I think the policy editors could handle this by deciding amongst
>> themselves how they want to interact with the TC and then writing
>> a note to the TC along the following lines adapted based on what
>> the policy editors think the write answer is:

Sean> Thank you for taking the time to think about this carefully,
Sean> but I would like to suggest that we set is aside until and
Sean> unless we have a concrete situation in which the Policy
Sean> Editors feel that we can't make a change to the Policy Manual
Sean> because of a particular T.C. decision.

Well, we have a situation now where a member of our community (Bill) is
uncomfortable with the TC being asked to take on one of the tasks that
our constitution lets the TC take on.
I think that concern is something that we should address now since it
has arisen.

If you as policy editors think that you can reassure Bill and tell him
that you believe you could work with the TC were that situation to come
up, then I think you could adress Bill's concern now without addressing
specifics.

Right now we have a situation where someone is concerned that one part
of Debian could not work with another.
I'd like to get that cleared up.  If the policy editors are confident
that they can defer things, I think that would be a fine solution.


--Sam

Re: Bits from the DPL (April 2019)

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> For package where upstream do not use the autotools, using dh
Bill> can be quite inconvenient compared to plain debhelper.

Bill> Cheers, -- Bill. 

I've started the discussion on debian-devel about whether we want to
recommend/require dh.
I think your comment belongs in that discussion not on debian-policy.
Please consider contributing there.

Re: Bits from the DPL (April 2019)

[Sam Hartman]

>>>>> "Bill" == Bill Allombert  writes:

Bill> On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote:
>> 
>> Now given our community it's entirely possible that the question
>> of whether it's a layering violation in our existing policy
>> architecture may influence whether people want to require it, so
>> we may have to face that sooner rather than later.
>> 
>> That said, it's been my experience as an engineer that interface
>> boundaries shift over time and that there are a lot of factors
>> that influence where we draw them.  As you pointed out in your
>> original mail, we do recommend specific tools including
>> dpkg-genchanges and dpkg-gencontrol.  I totally could generate a
>> changes file without using those tools.  In most cases we'd agree
>> that is a bug.
>> 
>> It seems fairly obvious that dpkg-dev is special and singular.

Bill> Note that policy does not actually require that dpkg is
Bill> used. Instead it goes to great length to describe what is the
 Bill> interface to dpkg that packages must relie on.

That's not really true.

policy>In the normative part of this manual, the words *must*, *should* and
policy>*may*, and the adjectives *required*, *recommended* and *optional*,
policy>are used to distinguish the significance of the various guidelines in
policy>this policy document. Packages that do not conform to the guidelines
policy> denoted by *must* (or *required*) will generally not be considered
policy> acceptable for the Debian distribution. Non-conformance with
policy> guidelines denoted by *should* (or *recommended*) will generally be
policy> considered a bug, but will not necessarily render a package unsuitable
policy> for distribution. 

Then later in 4.9:

policy>Both "binary-*" targets should depend on the "build" target, or on
policy>the appropriate "build-arch" or "build-indep" target, so that the
policy>package is built if it has not been already. It should then create
policy>the relevant binary package(s), using "dpkg-gencontrol" to make
policy>their control files and "dpkg-deb" to build them and place them in
policy>the parent of the top level directory.

Thus it is a bug to not use dpkg-genchanges and dpkg-gencontrol and
dpkg-deb.

 Bill> This makes
Bill> sense since this allow dpkg to evolve without breaking package
Bill> policy compliance.

Actually, I'd argue that mandating use of dpkg-genchanges et al makes
sense, as policy does today.
It allows dpkg to evolve and do things like update the checksums we use,
add new formats for changes files, etc and get wide adoption quickly
across the archive.

I'm not sure what sort of evolution you're talking about, but I think we
get better evolution by using a single tool that can easily be changed
than by using multiple tools to approach the same purpose.

Using multiple tools allows us to experiment and allows for cases where
different workflows/packaging designs work in different situations.
However it makes it harder to deploy new practices.

I think it's clear that at the dpkg-dev level, the benefits of multiple
tools are not justified, so policy correctly tells people to use tools
from dpkg-dev.

If you look at the question with a policy hat on, we might be asking
ourselves whether we have enough experience with the next level up that
telling people to use one tool at that next higher level is also worth
it.

Re: Bits from the DPL (April 2019)

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:

>> I plan to start with the question of preferring dh as a package
>> build tool.  https://trends.debian.net/ has already added not
>> using dh as a "package smell" and so I'd like to validate whether
>> the project agrees with that.  I'll start a discussion on
>> debian-devel about this issue the week of May 5.  While you can
>> of course start a discussion earlier or even start a meta
>> discussion about whether we should have a discussion or whether
>> I'm the right person to start it, I hope that doesn't happen.
>> I'm organizing some material to frame the discussion.  I
>> understand that if we make a change it is likely to be a policy
>> change.  So perhaps I could have started the discussion on
>> debian-policy rather than debian-devel.  I think that for the
>> high level question debian-devel is more appropriate.  If we get
>> down to details then shifting to -policy is likely to be a good
>> choice.

Sean> Policy currently documents an interface, and debhelper/dh is
Sean> an implementation of large parts of that interface.

Sean> Thus, it would be something of a layering violation if the
Sean> normative part of Policy were to require or recommend using a
Sean> particular tool to implement its other normative content.

I'll admit that I've been mostly focusing on how to canvas the project
about what it wants rather than how to implement it.

If we as a project actually want to require dh in some/most situations,
we ought to be able to figure out some way to say that.

Now given our community it's entirely possible that the question of
whether it's a layering violation in our existing policy architecture
may influence whether people want to require it, so we may have to face
that sooner rather than later.

That said, it's been my experience as an engineer that interface
boundaries shift over time and that there are a lot of factors that
influence where we draw them.
As you pointed out in your original mail, we do recommend specific tools
including dpkg-genchanges and dpkg-gencontrol.
I totally could generate a changes file without using those tools.
In most cases we'd agree that is a bug.

It seems fairly obvious that dpkg-dev is special and singular.

But we can shift that boundary if we want to.  The reason we've included
dpkg-dev in our boundary of things that we treat as singular is mostly
technical.

But boundaries (even of technical interfaces) can be placed for a
variety of reasons, some based around things like code maintainability
rather than technical necessity.
Factors like style, future evolution, and ease of deploying changes
affect how we as engineers treat abstraction every day.

Policy today has a number of requirements based on style.
We could allow each package to choose its approach for configuration
management.  Instead, we have a number of guidelines.  These guidelines
are not a technical necessity in a number of cases.
Instead, we have decided we value consistency  for our users.  We want
packages to have a reasonable configuration by default.  We want certain
behavior on upgrades.  We want to carefully control what happens for
conffiles.  Again, not entirely because of technical necessity, but also
because we want a consistent experience across the distribution for our
users.

We might also want a consistent experience across our distribution for
maintainers of packages beyond the minimum consistency required for our
tools to work.
If we do, shifting interface boundaries to permit that is entirely
reasonable.

It seems to me that whether something is a layering violation depends a
lot on what the layers are intended to do.
And sometimes refactoring is as much about rethinking why you have the
layers as actually moving things around.

Just my initial thoughts on this.

--Sam

Managing Frozen text when the TC Decides Policy

[Sam Hartman]

I'm not really sure that the point you bring up is all that related to
the question I was asking.
But I think the point you bring up is important and I hope relatively
easy to solve, so let's discuss it and try to solve it.

> "Bill" == Bill Allombert  writes:

Bill> In my view it is detrimental for the policy proces for the
Bill> Debian policy to include decisions made by the TC, because
Bill> this leads to a situation where some policy text is frozen
Bill> because the policy editors cannot change it without
Bill> potentially overriding the TC.

Thanks for bringing this up.

I agree that it would generally be unfortunate if we had policy text
that could not be changed by the policy process.  I can see rare
situations where it might happen: we might have legal advice requiring
specific text be included in packages under certain circumstances.  And
in such a situation it might well be that we'd expect the policy editors
to go back and check with lawyers before changing that frozen text.

I hope we don't run into that situation with the TC very often, and
can't see a lot of reasons why we would if we handle things correctly.

I want to solve this because I think it would be very detrimental if our
policy documents didn't reflect technical policy of the project.  And If
we decide it's detrimental for the policy document to include technical
policy that the TC decides under section 6.1.1 of our constitution,
we're effectively saying that we don't want the TC to decide technical
policy.  I don't want a situation where people need to go look at the
policy document and then separately go look through all the TC
resolutions.

Now, some TC resolutions are quite specific to a specific package or
situation and aren't within the scope of policy.  Others aren't even
setting technical policy.  But when the TC sets technical policy that
packagers should know about, I want to see that reflected in our policy
documents so that our policy documents remain useful.

I agree with you having frozen text in policy documents is undesirable,
and unless there's a good reason to do so we should avoid it.

I think the policy editors could handle this by deciding amongst
themselves how they want to interact with the TC and then writing a note
to the TC along the following lines adapted based on what the policy
editors think the write answer is:



Dear Technical Committee:

We wanted to clarify how we  we handle situations where you exercise
your power to set technical policy under Constitution section 6.1.1 and
where that decision should be reflected in Debian Policy.

Often it will make sense for you to include a diff to Policy in your
decision.  We will apply that diff.  As with all contributions to free
software, we will continue to refine and improve the contribution over
time.  In other words, we assume your decision is the intent of the
policy, and your text is intended as your best attempt to reflect that
in our document at the time you make the decision.  If there's text that
you do not want refined, please call that out and if we have any
concerns about that we will raise that.

As part of our normal process of evaluating changes to Policy, we will
consider whether those changes are consistent with decisions of the TC
and whether we need to ask for an override.  If we think their might be
a perception of conflict we'll let the TC know or ask for a specific
decision depending on how likely we think it is there is a conflict.  If
you think we've introduced changes into Policy that conflict with TC
decisions please open a bug.


In pa
particular: I don't think the specific text that the TC proposes is
generally frozen.  I think that's rarely the TC's intent.  I also think
that because of the separation between policy editors and TC, it's not
really clear to me that the TC can freeze text in Policy even if they
can set technical text for the project.  Thy can set policy; they
probably help everyone out by showing how that would fit into our
current Policy document.  The editors need need to produce a Policy
document that is consistent with the technical policy established by the
TC.  Of course if the editors think they can't do that they can throw up
their hands and quit (or more constructively point out the problem to
the TC).

Even beyond that, TC decisions are made based on a lot of context.  I
don't think it always needs a TC override to actually go against the
decision if the context has changed enough.  Sometimes the TC is good
about specifying the limits of the context.  For example as I recall
they were debating what the default init system would be for a
particular release, not as standing policy.

But even if the TC is imprecise about context, it shouldn't require an
override if that context has changed enough.  As an example, I don't
think anyone needed to go back to the TC to ask about using
/usr/bin/node for 

Thinking about Delegating Decisions about Policy

[Sam Hartman]

In my platform, one of the things I focused on is trying to drive the
decision process forward.

I imagine it won't be uncommon to get to a point where the right next
step is to develop technical or non-technical policy about something.

I'd like to focus in this message about what I as DPL do when I believe
we need to develop technical policy about some issue.  Typically this
will be after we'd had some project discussion and hopefully reached
some degree of consensus on the driving principles/overall approach for
the project.

Examples of the sorts of things I'm talking about would include
potential policy on use of dh after a discussion about our direction
there.


It seems that we have two overlapping groups that might be involved: the
policy editors (and more generally the consensus policy process) and the
Technical Committee.

Here's how as DPL I see things today.  I'm very open to changing my
mind, and this is very much just a starting position.

first, I've read
https://lists.debian.org/debian-project/2014/01/msg00044.html

I agree that the policy process can be delegated to the policy editors
by that mechanism and have no desire to change how policy works or
change the policy editors or anything like that.  I wouldn't mind seeing
the TC and policy editors work more closely together, and perhaps my
thoughts in this area are influenced by that.

That said, ultimately, I think the Technical Committee is the authority
on what our technical policy is under constitution section 6.1.1.

we delegated managing the process to the policy editors, but not the
actual policy decisions.  They make consensus calls.  They use their
judgment in a lot of ways.

But at least under the current process, the policy editors cannot  just
use their personal judgment to decide what policy is absent a consensus.


In contrast, while the TC cannot develop solutions, they can establish
policy using the collective judgment of the committee.
There's obviously some ambiguity in what it means to develop solutions
vs refining/wordsmithing proposals.

So, if I want to delegate deciding on a policy, who should I send it to?

My preference is to always send it to the TC.  But there's a big caveat
that I'll get to in a moment.

Why the TC?
A couple of reasons.

Ultimately they are the ones who can decide.
If things get stuck, they are in a position to make a decision.

The constitution makes it easy for the DPL to delegate almost anything
to the TC.

Once a specific decision is delegated, removing that delegation can be
thorny.  I think procedurally it's OK to remove a delegation because the
decision is stuck or no progress is being made.  However distinguishing
that from a situation where the delegate is making a decision (which
cannot be overturned by the DPL) can be thorny.

By delegating to the TC (and getting the TC to agree to accept a
delegated decision) I'm asking them to take ownership.  Once we agree
that they are handling it, we have agreement that the issue is important
enough to move forward.

But, and here's the caveat I talked about.  I think a reasonable way for
the TC to move forward on most issues I might bring to them is to give
the normal policy process including the policy editors a chance to come
to consensus.
"Ask someone else" is sometimes a great way to make something happen.

I think the TC procedurally could involve debian-policy for most policy
questions that come to them.  I think that it typically doesn't make
sense.  In a lot of cases it's clear that the normal policy process
isn't going to reach a consensus.  In cases where the normal policy
process hasn't been tried it might simply be reasonable for the TC to
decline to take up the issue until that has been tried.  But I can
imagine other cases where the approach I'm proposing would be
appropriate.

Of course the TC could turn around and tell me that I should try the
normal policy process first.  And if I do a bad job of identifying
issues that are important to the project or a bad job of guiding the
initial discussion, probably they should.  My hope is that if as DPL I
bring an issue that's actually important to the project to the TC, they
would be willing to track it, help me make sure we're making forward
progress, even if the first (and perhaps only) step is to build
consensus within debian-policy.

In effect, I'm asking the TC to help things move smoothly forward and to
become more involved if that becomes necessary.
I'm also asking the TC to work closely with debian-policy where
appropriate.

What are people's thoughts about this?

Will this approach work for the TC and policy editors?

Thanks for your consideration,

--Sam


signature.asc
Description: PGP signature

Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful

[Sam Hartman]

package: debian-policy
severity: normal

Hi. As part of reviewing an issue for the technical committee, I just
read policy section 9.3 in its entirety.

Section 9.3.1 really seems to be showing its age.  That section covers
runlevels and the sequencing numbers after S and K in rc.d links without
reference to dependency-based boot ordering, init systems other than
sysinit, etc.


In an ideal world I'd encourage that section to be updated to talk about
how boot ordering works on modern Debian.
Absent that, I'd recommend significantly trimming the section to just
cover the fact that there are run levels and that there are these
numbers after S and K and not go into what the numbers after S and K
mean.

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:
>> I agree that it would be the easier way and I also tried building
>> packages with patched GCC 5 setting PIE as default with success,
>> but we have a CTTE decision which says that we should set
>> hardening flags through dpkg:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Guillem> Meh, I'm not going to bother reading that bug report, but
Guillem> if that's what the decision really says, then that decision
Guillem> is just bogus…

So, first, the TC didn't actually make a formal decision.  The gcc
maintainer didn't like changing the compiler defaults; dpkg-buildflags
had gotten enough traction that it seemed to be a sufficient solution,
so the bug was closed with a specific note that any interested party
could reopen.

However, I think there are several factors that are different in this
situation:

* A big concern was introducing new warnings in environments where
  -Werror was in use.  That is something we sadly have a fair bit of
  experience fixing (-Wuninitialized springs to mind) since the time of
  that bug, and that seems not to apply to PIE

* More concerns about cases where the behavior would be wrong than seem
  to apply here.

Regardless of where you make the change you'll break some packages.
That happens though; both gcc and dpkg-dev have gotten more strict abouv
various behaviors in ways that break packages within recent memory.

So, I think there's some good reading in the TC bug about the proes and
cons of various approaches, but not all of it applies, and there is a
bit of flame to wade through mixed in with some generally well-thought
discussion.
That bug definitely should not be considered binding in general, but
definitely not in this environment.

--Sam

Re: Bug#802501: init script failures during postinst and related scripts

[Sam Hartman]

> "Daniel" == Daniel Pocock  writes:


I agree.
I think Henrique's advice is correct as far as it goes.
However as a distribution, I think we should explicitly encourage people
to consider the consequences on dist-upgrade and other operations.
For some daemons, where the system is likely to be totally broken,
having the installation break is probably the right answer.
If  the postinst is reasonably convinced that the problem is going to
make additional installation difficult (for example root partition or
/usr full) then failing also make sense.

However, for the vast majority of daemons, breaking installation is far
worse than a silent failure to restart.

I believe that this is a significant problem in Debian today andsystemd
makes this  a
significant regression of jessie over wheezy.
(Here I'm not saying systemd is bad; it does a better job of reporting
errors to postinst.; it just gives us behavior that sucks for our users)

--Sam

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

>>>>> "Wouter" == Wouter Verhelst <w...@uter.be> writes:

Wouter> On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote:
>> >>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes:
>> 
>> 
Wouter> So, I'm with Guillem on this one.
>> 
>> 
Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.
>> 
>> OK.  Then why don't you build consensus behind a patch to do
>> that?  The TC's decision can be changed by the normal policy
>> process.  If you can get people to agree with a proposal that
>> permits both ..desktop and .menu files then you can replace the
>> TC decision.

Wouter> Per §4.1.4, Only through a 2:1 supermajority
Wouter> GR. Alternatively, it could also by replaced by the TC
Wouter> voting a second time on the subject, changing or clarifying
Wouter> its original decision (an outcome I would favour, but hey,
Wouter> I'm not a member of the TC).

Normally that would be true.

However, the TC included the following language in its decision:

   6. Further modifications to the menu policy are allowed using the
  normal policy modification process.


My understanding is that Keith, Don and I at least intended that
language to allow the policy process to change or replace our decision.
I've run into three people now who did not find that clear.  If the
policy editors asked us to clarify that part of the decision I would
support doing so.  If the policy editors find that language clear enough
that they would feel comfortable merging a proposal that went against
the TC decision if it got enough seconds, etc, then I would find the
current language sufficient.

Re: Next update of the Policy ?

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> On Sun, Oct 04, 2015 at 12:07:02AM +0200, Bill Allombert wrote:
>> The GIT repository is only a tool for the policy editors. Due to
>> the decentralized nature of GIT, anybody can clone it anyway and
>> send a pull request.  Pushing to it directly is uselessly
>> interfering with the policy editors job.

Bill> Hello,

Bill> To allow everybody to forget about this infortunate accident
Bill> and let us continue to maintain the policy, I have reset the
Bill> master branch to the last commit before Charles intervention,
Bill> which is 282bd883. If you have already pulled Charles changes,
Bill> please reset your master branch.

When will you be merging in  ba679bff as adopted into Debian policy by
 the TC decision?


--Sam

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> So, I'm with Guillem on this one.


Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.

OK.
Then why don't you build consensus behind a patch to do that?
The TC's decision can be changed by the normal policy process.
If you can get people to agree with a proposal that permits both
.desktop and .menu files then you can replace the TC decision.

For myself, I think that forcing a transition to .desktop will create a
longer Debian long-term.  I believe that the TC's approach provides a
useful push for that in this situation.
I realize that it is a fairly forceful approach and it's not something
that Debian does often.
It seems to be a case where the broader community might disagree with
the TC and if that's the case, then I would be happy with that result.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:

Didier> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit
Didier> :
>> But _forbidding_ maintainers who want to from shipping a second
>> file, if that somehow makes the experience of menu users better
>> than what the fdo menu would have given them? Sorry, but that
>> seems petty and silly.

Didier> For context, the exact phrasing of the TC decision is
Didier> "packages providing a .desktop file shall not also provide a
Didier> menu file for the same application."

Didier> This translates to "this situation constitutes a bug", but
Didier> doesn't specify an explicit patch for the Debian Policy (aka
Didier> doesn't explicitly lay down the severity of the bug). I'd
Didier> argue that in the absence of a new Debian Policy version
Didier> incorporating the TC decision, such situations would be
Didier> 'serious' bugs. Can we work towards ironing an adequate
Didier> wording?

No, i don't think so at all.
It's quite clear from the TC minutes that serious was not intended, and
 there's no evidence that shall from the TC means the same
 thing as must in the policy.

When I read the message I feel a great frustration because I'm hoping
that we can work with respect.  It sounds like you are trying to build
up an interpretation that was never intended and create a bad
consequence for the status quo to drive resolution.
I do not support that.  I fully realize that it's easy to assume
motivations different than intended.

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Sam Hartman]

> "Marvin" == Marvin Renich  writes:

Marvin> As discussed on debian-devel starting at [1], I would like a
Marvin> comment added to Section 6.4 "Best practices for maintainer
Marvin> scripts" that recommends preventing the postinst script from
Marvin> returning failure when a service fails to start.

I strongly support this practice.

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Yeah, but there's a significant factor that reduces things somewhat.
In the past, /etc/init.d/foo failing would often cause postinst to
break.
However, in the past, there were a lot of failures that were not
detected by the init.d script.
We have two intentional decisions conflicting:

1) systemd tries to be a lot better about reporting service status than
our previous infrastructure

2) We had the decision on a number of people to not hide failures by
causing installation to fail.

I actually think the folks in category 2 weren't typically hiding a lot
of service failures, because  it was fairly common for the init script
to mask that, but it did tend to hide failures like missing
configuration files etc.

I certainly know that when deploying units for krb5 I had to mask a
bunch more failures to get behavior consistent with the previous
packages.

Given the above, I think a discussion on -devel (which has happened) and
a discussion on-policy is sufficient.

--Sam

Re: Next update of the Policy ?

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


Bill>  seems to have decided that the menu policy discussion
Bill> should take precedence over over issues (multiarch, systemd,
Bill> etc.) that are much more important.

Hi.  I do expect to see the part of the menu policy where the TC adopted
specific language in a version of the policy released reasonably soon.
I think it would be reasonable for any debian developer to NMU policy to
implement this change, uploading say to delayed/7 to give the editors a
chance to comment.

I do agree that the area where the TC did not adopt specific language
requires a proposal that reaches multiple seconds.  I'd expect the
policy editors to apply that patch reasonably promptly once it does get
those seconds; I do agree that this issue has reached a level of
priority where it is important to promptly put it behind us.  I don't
expect the policy editors to drive the discussion, but yes, I do expect
them to promptly reflect any conclusion the process reaches.


pgpao3pEeoikC.pgp
Description: PGP signature

Re: Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

I'm happy to engage in a constructive discussion with members of the
project on the advantages and disadvantages here.
The few times you and I have talked in person we've had useful
conversations and I think we learned from each other.

However, I need to be met with respect and a desire for understanding.

If you want to discuss this issue starting from the assumption that both
sides are working to make the best Debian we can; if you are willing to
start by listening rather than shouting; if you are willing to take the
time to understand the tradeoffs that  motivate those with whom you
disagree; then I will meet you.  I will take the time to understand your
position, I will respect your position even when I disagree with it, and
I will try my best to consider and learn from what you have to say.

Today, though, what I hear is that getting the last word in is more
important to you than that sort of connection and growth.
I am disappointed when I think about that.

Sam hartman
Debian Developer

Bug#792853: debian-policy: please disallow colons in upstream_version

[Sam Hartman]

>>>>> "Guillem" == Guillem Jover <guil...@debian.org> writes:

Guillem> Hi!
Guillem> On Mon, 2015-09-28 at 09:21:04 -0400, Sam Hartman wrote:
>> >>>>> "Charles" == Charles Plessy <ple...@debian.org> writes:
>> 
Charles> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a
Charles> écrit :
>> >> * Charles Plessy <ple...@debian.org>, 2015-09-24, 21:53: >- >>
>> : ~ (full stop, plus, hyphen, colon, >+ >>
>> : ~ (full stop, plus, hyphen,
>> >> 
>> >> Remove :, too.
>> 
Charles> Thanks for the proofreading.
>> 
Charles> With this correciton, are there people seconding the
Charles> proposed change ?
>> 
>> 
>> I'm totally fine with the text.  It's hard to say there's
>> sufficient support to judge consensus with so little discussion,
>> but I'll second under the following rationale.
>> 
>> This issue has been talked about so much, and the controversial
>> parts are already part of a TC decision.

Guillem> Hrmmm, what TC decision? Are you perhaps mixing up issues
Guillem> here?

I sure am.
However, I've also read the upstream colons discussion and can second
that with no problems what so ever:-)

(I will not second the other issue unless someone calls for seconds.)


pgpkVJ9ytJ_6J.pgp
Description: PGP signature

Bug#792853: debian-policy: please disallow colons in upstream_version

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a
Charles> écrit :
>> * Charles Plessy , 2015-09-24, 21:53: >-
>> : ~ (full stop, plus, hyphen, colon, >+
>> : ~ (full stop, plus, hyphen,
>> 
>> Remove :, too.

Charles> Thanks for the proofreading.

Charles> With this correciton, are there people seconding the
Charles> proposed change ?


I'm totally fine with the text.
It's hard to say there's sufficient support to judge consensus with so
little discussion, but I'll second under the following rationale.

This issue has been talked about so much, and the controversial parts
are already part of a TC decision.
If there were problems with the wording I expect someone would have
jumped up by now.
So, yeah, I think I can second.


pgpLSs7pP3B2S.pgp
Description: PGP signature