Re: Bug#915583: debian sphinx styling: second attempt

[Russ Allbery]

RL  writes:

> http://stephane.yaal.fr/tmp/release-notes/issues.html#grub-no-longer-runs-os-prober-by-default
> the '# dpkg-reconfigure ' is shown as a shell-comment, but is
> meant to be a command-to-run-as-root (i remember this being discussed on
> the previous version on the release-notes list, and i thought someone
> had posted a way to fix it?)

The sphinx-prompt extension plus using:

.. prompt:: bash
   :prompts: #

   dpkg-reconfigure 

will fix this, with the added bonus of removing the # prompt from the text
that is selected when the user cuts and pastes, so they can cut and paste
just the command.

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

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.

Re: Bug#915583: debian sphinx styling: second attempt

[RL]

Stéphane Blondon  writes:

>  - for (draft sphinx) release-notes: 
> http://stephane.yaal.fr/tmp/release-notes/
>
> What do you think about it?

commenting on the release-notes, but i expect applies to policy too:

looks awesome - imo it is now even better-looking than the docbook verison

in the tables, eg package list under
   http://stephane.yaal.fr/tmp/release-notes/whats-new.html runningnthe
   mouse over the rows and headers does some changes to the font which
   is a bit confusing, eg the "dark" rows end up near-white on white:
   suggest disabling this

http://stephane.yaal.fr/tmp/release-notes/issues.html#grub-no-longer-runs-os-prober-by-default
the '# dpkg-reconfigure ' is shown as a shell-comment, but is
meant to be a command-to-run-as-root (i remember this being discussed on
the previous version on the release-notes list, and i thought someone
had posted a way to fix it?)

When things are in the orange-on-grey boxes it looks to me like the grey
   boxes are not quite vertically centred, eg in
   
http://stephane.yaal.fr/tmp/release-notes/issues.html#rsyslog-changes-affecting-log-analyzers-such-as-logcheck

   the 'rsyslog' beofre the closing parenthesis the top of box is
   aligned to the top of the ")" but the bottom of the box extends
   below)

  (and i wonder if a slightly darker (ie red-er) orange would be a bit
  more readable, or wether changing foreground and adding the box is a
  bit much?)

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

[Santiago Vila]

El 17/9/23 a las 0:12, Daniel Gröber escribió:

Sam, Russ, Bill,

Thanks for your input. To be quite frank I still don't see how the
interpretation of allowing configuration files outside of /etc can be
supported based on the policy text.


Hello. I apologize for not having read the discussion in full.

I believe there is an underlying semantic problem here.

Those files were shipped in /etc before. They are not shipped
in /etc anymore. Instead, files with identical contents
are now shipped in /usr/lib.

In your eyes, this is enough to consider that the files
have "moved", and maybe that's why you are still calling
them "configuration files outside of /etc".

But this is all about intent. It's not the format of the file
or the way they modify the behaviour of the program what
makes them to be "configuration files". It's the intent.

If the files are intended to be modified "in place" by the
system admin, we call them configuration files (and we try hard
to put them in /etc). If they are not intended to be modified by
the system admin, we don't call them configuration files (and
we try hard not to put them in /etc).


So I maintain that the current policy text doesn't allow configuration
files outside of /etc.


I agree, and this is why I think there is a semantic problem. The way I see it,
the problem is not really that there are "configuration files outside of /etc",
the problem is calling them configuration files when they are not anymore.

The definition of "configuration file" may not be perfect, but we have
to be careful not to twist it too much, because we might find ourselves
in the difficult position that lots of files in /usr/lib would also be
"configuration files outside of /etc".

That's why I believe intent is essential here.

Thanks.

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

[Alexandre Detiste]

Le dim. 17 sept. 2023 à 01:15, Russ Allbery  a écrit :
> Luca Boccassi  writes:
>
> One would need to duplicate empty directories in /var (that don't have
> dynamic ownership).  I'm dubious that's a significant burden (it's two or
> three lines in debian/rules), but if it is,
> one could even automate this
> in debhelper by parsing tmpfiles.d if one really wanted to.

That would be awesome. The less (open) code in d/rules, the better.

There's already this draft RM that this feature could build upon.
https://salsa.debian.org/debian/debhelper/-/merge_requests/102/

Greets

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

[Russ Allbery]

Daniel Gröber  writes:

> Ultimately I'm just concerned about the UX aspects of admins suddenly
> having to go hunting for config files all over their system when
> packages start implementing this config-in-/usr business en mass.

I think the expectation is that you read the documentation of the package
that you're configuring, just as if the defaults were all hard-coded in
the binary.  I realize that some people *prefer* to have all of the
configuration of a package documented in comments or settings in a
template file installed into /etc, but this has never been something we
*required*, just a convention that some packages follow and some do not.

> I don't really mind if we go that way but then policy needs to be
> updated and some convention or mechanism[1] put in place to make working
> with config by hand as easy as it's been in the past, but that work is
> on the devs pushing the project in that direction.

This is a change that is mostly happening in the upstream development of
some packages, so I think your attribution of cause may not be entirely
accurate.  People are adapting Debian packages to a configuration model
that started in other distributions and has been adopted by the upstreams
of those packages, and some of them are also advocating for this
configuration practice as a good idea, but the push of Debian in that
direction would be happening regardless of the opinions of Debian
maintainers about this configuration method.  Some of our upstreams are
adopting this and it's highly unlikely that we would maintain local
patches to undo that change.

I'm not sure how much of the documentation belongs in Policy, since this
is really user-facing documentation, which is entirely outside the remit
of Policy.  Policy is only about packaging; we don't expect users of
Debian systems to read it.  But I'd be happy to review a patch that
updated the Policy wording of configuration files to make it clear that
"configuration files" only refers to the files edited by administrators in
the course of configuring the system, not to wherever the read-only
configuration defaults may be stored.

Obviously if someone wants to write better tools to manage these
configuration files, that would be great, but that's outside the scope of
this list, and I am dubious that we would refuse to update to newer
upstream versions of our packages until someone writes such a tool.  We
are part of a larger ecosystem, and some critical components of that
ecosystem are moving in this direction regardless of what we do.

> On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote:

>> Configuration file has a very specific meaning in Policy: it's a file
>> that the local system administrator changes in order to configure the
>> software.

> Sorry, I don't buy that. Policy is kind enough to have an explicit
> definition for what it means by "configuration file" in
> 10.7.1. Definitions:

>> configuration file
>> 
>> A file that affects the operation of a program, or provides site- or
>> host-specific information, or otherwise customizes the behavior of a
>> program. 

> "A file that affects the operation of a program" pretty clear cut to
> mean exactly the type of files at issue here.

I understand that this is not what you want this part of Policy to mean,
but a "configuration file" in Policy has always been the file that you
edit to change the operation of the program.  It is not a *requirement*
that every file shipping with the package that contains configuration
defaults be installed in /etc.  Given the number of packages that
hard-code configuration defaults into the binary and put them nowhere else
on the file system at all, this would not be possible.

It is *common* for a package to install a configuration file that has some
or all of the defaults, as a template for local administrators to modify,
but there have always been packages that do not do this, and other
packages that do this for some configuration files and not others.  There
have always been some packages that put the defaults or the configuration
template elsewhere, whether that be /usr/share/doc//examples or
hard-coded into some binary.

Packages that use this "empty default /etc" configuration approach do not
ship *any* configuration files under the Policy definition.  They only
ship binaries and data files for those binaries that contain default
settings.  Those files are not modifiable and are not configuration files
in the Policy sense.  From a Policy perspective, they're exactly like the
files installed in /usr/share/pam-configs, /usr/share/doc-base, or
/usr/share/applications, which are also files that affect the operation of
a program.

I agree that the wording in Policy could be clearer.

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

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

[Russ Allbery]

Luca Boccassi  writes:

> Aside from more practical considerations, shipping /var content in
> packages is problematic because it's supposed to be local variable data,
> that can be removed without breaking a system.

Unless I'm missing something, including the directory in the deb won't
make any difference here.  dpkg won't break if a directory that was
included in the package is deleted.  It would show as an inconsistency if
someone checked the file system against the dpkg database, but as soon as
systemd-tmpfiles runs, it will create the directory again and fix the
inconsistency, so I don't see what problems that would create.

> More practically, one of the purposes of the hermetic-usr pattern is to
> allow several modernizations. The easiest one to achieve is to create
> /var/ on firstboot, and encrypt it against the tpm, so that it can be
> enabled by default, always, so we can't have packages ship and expect
> content in /var from their packages.

(I am a little confused by this wording, but I think what you're saying is
that /usr is encrypted and read-only, and /var is recreated on each boot.
That at least is my understanding of the pattern that you're trying to
enable.)

Here too, I don't see how including an empty directory in /var in the deb
will make any difference here.  When you create such a system, you would
delete /var, so it wouldn't matter if packages created files in there (and
in fact, under every proposal in this bug, installing packages *would*
create files there, since systemd-tmpfiles would be invoked by the
maintainer scripts anyway).

> On top of that, as you mentioned already things will inevitably get out
> of sync, and one will have to duplicate everything.

One would need to duplicate empty directories in /var (that don't have
dynamic ownership).  I'm dubious that's a significant burden (it's two or
three lines in debian/rules), but if it is, one could even automate this
in debhelper by parsing tmpfiles.d if one really wanted to.  The main
thing that could get out of sync is the ownership, which is indeed not
ideal, but I'm also not sure it's going to cause major problems even if
people do get it wrong.  I was trying to remember if dpkg changes
directory (as opposed to file) ownership if it sees a directory owned by
an unexpected user.  I kind of think it doesn't, but I'm not sure about
that.

The benefit we gain from this is attribution of the directories in the
dpkg database, which is useful (although I understand that one can argue
about how useful).

So... I think the answer to my question of whether this will interfere
with your use case is no?  I understand that you don't want to do it, and
expected that, and that opinion is important for the discussion, but I'm
also trying to figure out if it will *break* anything.

> And if dpkg gets the ability to read tmpfiles.d - then that's great,
> and even more reasons not to change policy for something that would
> only be a temporary stop-gap.

I'm not going to assume that this is going to happen on any particular
time scale.  dpkg has to gain a mechanism for registering transient files
first, which in my understanding depends on other significant dpkg
architectural work.

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

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

[Russ Allbery]

Simon McVittie  writes:

> The key piece of information that was missing from your previous
> proposal was that systemd-tmpfiles interface versions match upstream
> systemd version numbers. As a concrete example, if someone wants to
> upload an implementation other than the one from systemd, it cannot have

> Provides: systemd-tmpfiles (= 254)

> until it has at least a basic implementation of the new "X", "C+" and
> "--graceful" features introduced in systemd 254.

Yeah, I had missed that, thank you.  I think that's now captured.

> If the package benefits from running tmpfiles.d but does not strictly
> require it (for example dbus-daemon, where /run/dbus/containers is
> needed for some optional functionality), would a Recommends or Suggests
> be allowed by this wording, or are we intending for this to be a
> mandatory hard dependency?

I'm not sure it's going to make a lot of difference in practice, since I
think it will be hard to end up with a system that doesn't have a
systemd-tmpfiles implementation installed, but I agree that in theory this
is too strong.  I'll try to come up with a rewording that allows for the
possibility of Recommends or Suggests.  Maybe just a parenthetical that
says or Recommends or Suggests if this more accurately fits the nature of
the dependency?

I think apart from this and resolving whether to add empty directories
into the deb, the remaining issue before we can merge this is to make sure
that the sysvinit maintainers are okay with adding the requirement that
the init system invoke a systemd-tmpfiles implementation periodically.  As
I would expect, the systemd-standalone-tmpfiles package only provides the
binary, not any init system integration.  Does anyone know if that
integration has already been done to invoke systemd-tmpfiles during boot
on systems using sysvinit?

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

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

[Luca Boccassi]

On Fri, 15 Sept 2023 at 22:18, Russ Allbery  wrote:
>
> Guillem Jover  writes:
>
> > Not shipping these empty directories in the .deb seems like a regression
> > or a disservice to me. Even for things that might get deleted because
> > things like our policy or the FHS allows for it (say stuff under
> > /var/cache), as «dpkg --verify» can be useful. Because of course, these
> > in addition, can be defined via tmpfiles.d, so that they can possibly be
> > recreated if needed (until dpkg provides its own interfaces to do that).
>
> Luca, are there any drawbacks for your purposes in both shipping the
> directories in the deb *and* defining them with tmpfiles.d for those cases
> where it is possible to ship them in the deb (no dynamic owner or group,
> for instance)?  At first glance, it feels like this should be fine, since
> tmpfiles.d will recreate the directories and dpkg will then be happy with
> them.
>
> It does potentially create problems if dpkg and tmpfiles.d have different
> ideas about what the ownership or permissions of the directories should
> be, but at present I don't think such conflicts would create a lot of
> practical problems (tmpfiles.d should essentialy always win), so I think
> it's a fairly minor point.
>
> It's a bit more complicated to specify in Policy because it's not possible
> to include the directory in the deb file in cases where it needs to have
> ownership set based on users or groups created dynamically by the
> maintainer scripts, but hopefully not overly complicated.

Aside from more practical considerations, shipping /var content in
packages is problematic because it's supposed to be local variable
data, that can be removed without breaking a system. This is by
definition not the case if the system's state becomes inconsistent
because packages, that have fixed content, ship files that can then be
removed locally. This is one of the many reasons why recently rpm
moved its database into /usr, as that's really what it is tied to and
where packages ship files into. AFAIK a few people have already
started some time ago to fix this on a package-by-package basis -
fortunately it's not that many, iirc.

More practically, one of the purposes of the hermetic-usr pattern is
to allow several modernizations. The easiest one to achieve is to
create /var/ on firstboot, and encrypt it against the tpm, so that it
can be enabled by default, always, so we can't have packages ship and
expect content in /var from their packages. This is a concrete and
achievable step forward to catch up to other OSes, as Linux is
embarrassingly behind Windows and OSX on the security aspect, and we
have a lot of work to do.

On top of that, as you mentioned already things will inevitably get
out of sync, and one will have to duplicate everything. Also
inevitably it will end up being wrong in cases where different
metadata has to be specified, with conflicts. This seems just busywork
that we can spare ourselves.

And if dpkg gets the ability to read tmpfiles.d - then that's great,
and even more reasons not to change policy for something that would
only be a temporary stop-gap. rpm recently gained native support for
sysusers.d and I believe they are looking into tmpfiles.d next, so
it's the right thing to do regardless.

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

[Daniel Gröber]

Sam, Russ, Bill,

Thanks for your input. To be quite frank I still don't see how the
interpretation of allowing configuration files outside of /etc can be
supported based on the policy text.

Ultimately I'm just concerned about the UX aspects of admins suddenly
having to go hunting for config files all over their system when packages
start implementing this config-in-/usr business en mass.

I don't really mind if we go that way but then policy needs to be updated
and some convention or mechanism[1] put in place to make working with
config by hand as easy as it's been in the past, but that work is on the
devs pushing the project in that direction.

[1]: Josh had an interesting idea over in a relate d-devel thread:
"sysadmin configuration of sparse-/etc vs prepopulated-/etc?"
https://lists.debian.org/debian-devel/2023/09/msg00192.html

Perhaps by having /usr/etc which must mirror where files go in /etc?
Right now different packages seem to put files in random places, some in
/usr/share some in /usr/lib. Madness.

If this becomes more common I fear it's going to cause a lot of friction
for root users. Remember: those are the ones with the power to just
uninstall Debian and replace it ;) 

On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote:
> Configuration file has a very specific meaning in Policy: it's a file that
> the local system administrator changes in order to configure the software.

Sorry, I don't buy that. Policy is kind enough to have an explicit
definition for what it means by "configuration file" in
10.7.1. Definitions:

> configuration file
> 
> A file that affects the operation of a program, or provides site- or
> host-specific information, or otherwise customizes the behavior of a
> program. 

"A file that affects the operation of a program" pretty clear cut to mean
exactly the type of files at issue here. Policy goes on to suggest that
such a file might typically be intended to be edited by the admin:

> Typically, configuration files are intended to be modified by the system
> administrator (if needed or desired) to conform to local policy or to
> provide more useful site-specific behavior.

Note how this is not a requirement for a file to be captured by this
definition.

So I maintain that the current policy text doesn't allow configuration
files outside of /etc.

--Daniel


signature.asc
Description: PGP signature

Bug#915583: debian sphinx styling: second attempt

[Russ Allbery]

Stéphane Blondon  writes:

> I've done a new version. It's based on 'sphinx_rtd_theme' theme. So, to
> build the site, the package 'python3-sphinx-rtd-theme' requires to be
> added to dependencies. A new file 'debian.css' is specific to set some
> colors and renderings.

> Reusing 'Read the docs' theme allows to have a responsive design
> automatically.

> The theme could be modified more but it could be considered as a first
> step which is already usable.

> There are temporary demos available:
>  - for debian-policy: http://stephane.yaal.fr/tmp/policy/
>  - for (draft sphinx) release-notes: 
> http://stephane.yaal.fr/tmp/release-notes/

> What do you think about it?

Hi Stéphane,

Thank you so much for this!  I poked around a little bit on your draft
render of Policy and personally I'm quite happy with it.  The sidebar
management with small screens seemed to work for me and is definitely
better that what we have right now.  I would encourage others to also take
a look and provide feedback.  My inclination is to merge this in a future
release of Policy.

The one minor thing that I noticed was that the version number of Policy
in the left sidebar at the top is very difficult to read because it's
almost the same color as the background.

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

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

[Russ Allbery]

Bill Allombert  writes:

> One of the issue in the past is that reproducible build was broken
> because different build environment lead to different paths. We at least
> need to address that.

I believe the reproducible build problem specifically will be largely
fixed by /usr-merging the buildds so that they look like all other Debian
systems.  I suspect the problems that you ran into in the past were
precisely because some systems on which the package was built were
/usr-merged and others were not.  But you make a good point that just
because the /bin and /usr/bin paths both work does not mean that package
build systems can pick randomly between them, since that undermines build
reproducibility.  They need to pick one or the other consistently.

I do think packages should be allowed to do a PATH search, and it's up to
the people doing a reproducible build to make sure the PATH stays
consistent from one build to the next.

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

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

[Russ Allbery]

Sam Hartman  writes:

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

To be clear, I personally agree with this, and I am sure that I will use
/bin/sh until the end of time, even if every extant UNIX system decides to
create a /usr/bin/sh alias for it (one way or the other).

But from an interface perspective, I think it adds some clarity to think
of it this way: When people started merging /bin and /usr/bin, they added
a new /usr/bin/sh interface for invoking the Bourne shell.  They may not
have intended to do this, but that's what they did, and there was nothing
inherent in the system to prevent people from using that interface.  So
people started doing so.

I'm sure that I'm not the only one who has encountered #!/usr/bin/sh
scripts in the wild, usually because the person who wrote the script was
using some Red Hat or Fedora distribution and didn't really think about
it.  Either they were used to the /usr/bin pattern from Perl and Python or
they ran "which sh" and, as Bill points out, that returns /usr/bin/sh,
etc.  Up until now, those scripts didn't work on Debian systems, which
caused some minor annoyances.  Now they do.

What has essentially happened given the number of distributions that have
done /usr-merge is that Linux has added /usr/bin/sh as a new interface
that is interchangeable with /bin/sh, and now nearly every current Linux
system you run across will also support that interface.  This is annoying
for UNIXes that don't support that interface (I don't know what the BSDs
are doing, for instance), but it's fairly invisible to users unless they
care about portability to non-Linux systems.  I care about portability to
non-Linux systems in at least some situations, but a lot of people don't.

(Incidentally, this interface argument is also why I have some nit-picks
about the wording of Luca's proposed patch, because the guarantees in
Policy apply specifically to /bin/sh and /usr/bin/sh, not to, say,
/usr/local/bin/sh or /usr/xpg4/bin/sh or whatever.  This is an admittedly
very minor point.)

> I care a lot that we use /bin/sh in our documentation and examples
> (especially in policy).

I agree with this.  If we write example scripts, I think they should use
#!/bin/sh.  I don't think my (b) proposal is arguing against that; (b)
says that both paths work and you can use either of them, and Policy will
chose to use /bin/sh at least for the time being because, well, I'm one of
the Policy Editors and I care about things like that.  :)  I think Policy
would only use /usr/bin/sh in documentation and examples if we adopted
(c), which based on the discussion so far seems unlikely.

> I care a lot that we point out that the reality of the situation is
> people will see other paths.

This is the part that I'm really focusing on at the moment, because I
think it's what people are really asking and what directly addresses the
concern about bug reports asking maintainers to switch from /usr/bin/sh to
/bin/sh.  If Debian is going to contain scripts that use /usr/bin/sh, this
is a change and we should say so explicitly.

Bill pointed out precisely the way that I expect this to happen: a lot of
packages use PATH searches in their build systems to find common tools,
and although I think this is ill-advised, some of them do that for sh
(mostly because of old Solaris breakage).  As soon as the buildds are
/usr-merged, those packages are going to start using /usr/bin/sh instead
of /bin/sh because it's first in the PATH, assuming the buildds use the
same PATH setup as /etc/login.defs (I don't know if this is the case).
And the question is do we tell maintainers that they should fix this, or
do we accept that it will happen and not worry about it?

I personally probably would find a way to force /bin/sh somewhere because
I am a perfectionist, but it requires overriding the upstream build system
and maintaining that code going forward and a lot of maintainers aren't
going to want to bother.  I think Policy should provide some guidance to
both maintainers and bug reporters here about what we expect.

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

Precisely.  To me, that's the heart of the (b) position, although people
advocating for (b) are going to vary from "prefer /bin" to "prefer
/usr/bin" and (b) is sort of inherently a compromise position about what
we're going to *do* among people who have different preferences about
style.

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

Yeah, it sounds like you're thinking of exactly the case I was thinking
of.

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

> 1) Policy should 

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

[Russ Allbery]

Control: unblock 1051371 by 1050001

Ansgar  writes:

> However, there is a proposal by Jackson for an alternative filesystem
> layout based on symlink farms in consideration by the technical
> committee.  This advocates removing compat symlinks in /bin, /sbin over
> time[1], thus requiring (c).

This is not a correct summary of Ian's proposal.  In the message that you
linked, Ian says:

/bin and /lib etc. remain directories (so there is no aliasing).  All
actual files are shipped in /usr.  / contains compatibility symlinks
pointing into /usr, for those files/APIs/programs where this is needed
(which is far from all of them).  Eventualloy, over time, the set of
compatibility links is reduced to a mere handful.

I am absolutely certain that Ian would consider /bin/sh to be one of the
programs for which a compatibility symlink is needed, and one of the
remaining handful of links that would exist indefinitely into the future.
Indeed, he mentions /bin/sh explicitly later in that message.

Given that, I believe Ian's proposal is orthogonal to this bug.  For
/bin/sh and /usr/bin/sh, it would create the same aliasing and thus would
create the same question about how to talk about those paths in Policy.  I
therefore don't think resolution of this bug blocks on the TC bug.

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

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

[Debian Bug Tracking System]

Processing control commands:

> unblock 1051371 by 1050001
Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters
1051371 was not blocked by any bugs.
1051371 was not blocking any bugs.
Removed blocking bug(s) of 1051371: 1050001

-- 
1051371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Debian Bug Tracking System]

Processing control commands:

> unblock 1051371 by 1050001
Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters
1051371 was blocked by: 1050001
1051371 was not blocking any bugs.
Removed blocking bug(s) of 1051371: 1050001

-- 
1050001: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050001
1051371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems