Bug#880992: debian-policy should not recommend running editor using absolute path

[Sean Whitton]

Hello Jonathan,

On Wed, Nov 08 2017, Jonathan Nieder wrote:

> I understand and agree, but that doesn't mean that packages should
> invoke editor using an absolute path.
>
> Policy describes package behavior, not user behavior.

Right.  In this case, though, it describes package behaviour meant to
avoid getting in the way of user behaviour.

> Further, a sysadmin on a shared machine doesn't have a way to set
> EDITOR for all users, but they can install an editor command to
> /usr/local/bin/.  I've seen sysadmins at a university do something
> similar for e.g. a custom build of gcc.  It would be more robust for
> the sysadmin to use alternatives instead, but I'm just saying it's
> more polite for a package to respect what the user was trying to do.

That's a good point about /usr/local/bin/, and I think it defeats my
suggestion.  Enabling local admins to make use of /usr/local/bin/editor
is more important than enabling (unusual) users to have ~/bin/editor not
be an editor.

>>This seems sensible because 'editor' and
>> 'pager' are fairly generic terms and a user might have things in
>> ~/bin/editor or ~/bin/pager that don't edit or page, respectively.
>
> Really?  That would be a reason for the 'editor' and 'pager' commands
> to be named something else.  But on the contrary, I find 'editor' and
> 'pager' to be pretty clear names for what they do.
>
> Is there additional information or context I can provide to change
> your mind?

I should be clear that I'm not really objecting, just trying to
understand why the current wording is the way it is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#880920: Document Rules-Requires-Root field

[Sean Whitton]

Hello Ian,

On Wed, Nov 08 2017, Ian Jackson wrote:

> Sean Whitton writes ("Bug#880920: Document Rules-Requires-Root
>field"):
>> I wonder if we should just make Policy the new home of the spec that
>> Niels and Guillem have already written?
>
> I certainly would rather not block incorporation of this new spec into
> Debian's official document set, on the task of reformatting it into
> docbook.
>
> So yes it should probably go into the policy package (since there is
> no better home for it).

Given that we are now rST I think we should not just dump the spec into
the policy package, but hold out on a patch to the manual itself, since
writing such a thing is not very hard at all.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#880992: debian-policy should not recommend running editor using absolute path

[Bill Allombert]

On Wed, Nov 08, 2017 at 12:31:09PM -0800, Jonathan Nieder wrote:
> Hi,
> 
> Sean Whitton wrote:
> > On Mon, Nov 06 2017, Jonathan Nieder wrote:
> 
> >>Thus, every program that launches an editor or pager must use
> >>the EDITOR or PAGER environment variable to determine the editor
> >>or pager the user wishes to use. If these variables are not set,
> >>the programs /usr/bin/editor and /usr/bin/pager should be used,
> >>respectively.
> >>
> >> If read strictly, this says that I must use "/usr/bin/editor" instead
> >> of invoking "editor" from the $PATH.  (I'm not sure I agree with that
> >> interpretation, but it came up in https://bugs.debian.org/682347.)
> >> Running "editor" from the $PATH instead of using that full path should
> >> be perfectly acceptable and IMHO is a better behavior, since it allows
> >> the user to put a custom editor in /usr/local/bin or $HOME/bin.
> >
> > ISTM that the intention is for the user to set EDITOR and PAGER to
> > select an editor or pager, rather than putting things called 'editor'
> > and 'pager' into PATH.
> 
> I understand and agree, but that doesn't mean that packages should
> invoke editor using an absolute path.
> 
> Policy describes package behavior, not user behavior.
> 
> Further, a sysadmin on a shared machine doesn't have a way to set
> EDITOR for all users,

Why not ? PAM can do it, see /etc/environment?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#880992: debian-policy should not recommend running editor using absolute path

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Nov 06 2017, Jonathan Nieder wrote:

>>  Thus, every program that launches an editor or pager must use
>>  the EDITOR or PAGER environment variable to determine the editor
>>  or pager the user wishes to use. If these variables are not set,
>>  the programs /usr/bin/editor and /usr/bin/pager should be used,
>>  respectively.
>>
>> If read strictly, this says that I must use "/usr/bin/editor" instead
>> of invoking "editor" from the $PATH.  (I'm not sure I agree with that
>> interpretation, but it came up in https://bugs.debian.org/682347.)
>> Running "editor" from the $PATH instead of using that full path should
>> be perfectly acceptable and IMHO is a better behavior, since it allows
>> the user to put a custom editor in /usr/local/bin or $HOME/bin.
>
> ISTM that the intention is for the user to set EDITOR and PAGER to
> select an editor or pager, rather than putting things called 'editor'
> and 'pager' into PATH.

I understand and agree, but that doesn't mean that packages should
invoke editor using an absolute path.

Policy describes package behavior, not user behavior.

Further, a sysadmin on a shared machine doesn't have a way to set
EDITOR for all users, but they can install an editor command to
/usr/local/bin/.  I've seen sysadmins at a university do something
similar for e.g. a custom build of gcc.  It would be more robust for
the sysadmin to use alternatives instead, but I'm just saying it's
more polite for a package to respect what the user was trying to do.

>This seems sensible because 'editor' and 'pager'
> are fairly generic terms and a user might have things in ~/bin/editor or
> ~/bin/pager that don't edit or page, respectively.

Really?  That would be a reason for the 'editor' and 'pager' commands
to be named something else.  But on the contrary, I find 'editor' and
'pager' to be pretty clear names for what they do.

Is there additional information or context I can provide to change
your mind?  Note that the change I am proposing is to allow packages
to invoke 'editor' from $PATH, not to require them to do so.  There
are existing packages (e.g., Git) that already do this.  This is
similar to upstream packages invoking "less" or "more" from the $PATH
instead of relying on it to be at a particular path.

Jonathan

Bug#881166: log files, postrotate example: start-stop-daemon or invoke-rc.d?

[Russ Allbery]

Daniel Pocock  writes:

> In the section on log files[1], the example uses start-stop-daemon:

> postrotate
> start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
> endscript

> while elsewhere in the policy manual it is suggested to use invoke-rc.d

> Inspecting my own system, I noticed most logrotate scripts use
> invoke-rc.d, not start-stop-daemon

There was a long discussion about this a while back, during which we
decided not to change this because of bad interations with policy-rc.d, I
think?  I'm not sure what the bug number was, though.

I agree that the behavior you're describing seems broken.

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

Bug#880920: Document Rules-Requires-Root field

[Russ Allbery]

Ian Jackson  writes:
> Sean Whitton writes ("Bug#880920: Document Rules-Requires-Root field"):

>> I wonder if we should just make Policy the new home of the spec that
>> Niels and Guillem have already written?

> I certainly would rather not block incorporation of this new spec into
> Debian's official document set, on the task of reformatting it into
> docbook.

Policy is now reStructuredText, so hopefully the reformatting for any
future specs will be much, much easier.

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

Re: Bug#881166: log files, postrotate example: start-stop-daemon or invoke-rc.d?

[Simon McVittie]

On Wed, 08 Nov 2017 at 13:50:31 +0100, Daniel Pocock wrote:
> Imagine the following scenario:
> 
> - a package distributes an init script that runs the process with a PID file
> 
> - later on, the package maintainer starts distributing a systemd unit
> file as well, running the process in foreground without a PID file, but
> the init script is still included in the package too
> 
> In this case, when the package is installed on a systemd system,
> start-stop-daemon would never find a PID file and rotation doesn't work.

If the package doesn't distribute a native systemd unit (yet), then this
isn't a bug (yet). If the package does, then I think you're right that
the logrotate snippet needs to change, at the same time the systemd
unit changes from the one generated by systemd-sysv-generator to one
that doesn't use start-stop-daemon.

Using "invoke-rc.d mydaemon force-reload" would be more future-proof.

> Some scripts also appear to make a check if invoke-rc.d really exists
> and then fall back to "service foo reload"

This should probably not be recommended or allowed, for the same reasons
that §9.3.3.2 doesn't allow it in maintainer scripts. invoke-rc.d was
non-Essential long ago, but is now Essential.

smcv

Bug#880920: Document Rules-Requires-Root field

[Ian Jackson]

Sean Whitton writes ("Bug#880920: Document Rules-Requires-Root field"):
> I wonder if we should just make Policy the new home of the spec that
> Niels and Guillem have already written?

I certainly would rather not block incorporation of this new spec into
Debian's official document set, on the task of reformatting it into
docbook.

So yes it should probably go into the policy package (since there is
no better home for it).

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#881166: log files, postrotate example: start-stop-daemon or invoke-rc.d?

[Daniel Pocock]

Package: debian-policy
Version: 4.1.1.1

In the section on log files[1], the example uses start-stop-daemon:

postrotate
start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
endscript

while elsewhere in the policy manual it is suggested to use invoke-rc.d

Inspecting my own system, I noticed most logrotate scripts use
invoke-rc.d, not start-stop-daemon

Imagine the following scenario:

- a package distributes an init script that runs the process with a PID file

- later on, the package maintainer starts distributing a systemd unit
file as well, running the process in foreground without a PID file, but
the init script is still included in the package too

In this case, when the package is installed on a systemd system,
start-stop-daemon would never find a PID file and rotation doesn't work.

Some scripts also appear to make a check if invoke-rc.d really exists
and then fall back to "service foo reload":

postrotate
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d foo rotate > /dev/null
else
if [ -f /var/run/foo.pid ]; then
/etc/init.d/foo rotate > /dev/null
fi
fi
endscript


Should the debian-policy example be changed to invoke-rc.d or to
something more elaborate?

Regards,

Daniel


1. https://www.debian.org/doc/debian-policy/#log-files