Bug#881166: log files, postrotate example: start-stop-daemon or invoke-rc.d?
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
Re: Bug#802501: init script failures during postinst and related scripts
On 22/10/15 12:26, Henrique de Moraes Holschuh wrote: > On Tue, Oct 20, 2015, at 14:08, Daniel Pocock wrote: >> If postinst or one of the other scripts does a service restart and the >> restart operation fails, should the postinst abort or should it mask the >> error, continue and return success? > > Whatever makes more sense for that particular service, as in "safer". > And by safer I do mean: smaller chance of aggravating already present > damage, causing security issues, or data loss". > Ok, I thought about this some more in terms of what should be in the policy document It is a situation of minimizing damage: if one of the pre* or post* scripts fails during a big dist-upgrade, it sometimes leaves the system in a very bad state. Being able to "apt-get dist-upgrade" the same box every 2 years is one of the beautiful things about Debian that people respect. So, I feel that by default, if errors occur when trying to stop or start services, the policy should encourage people to write the scripts in such a way that they continue anyway. If somebody really cares about whether a particular daemon is running at the end of their upgrade, they should be monitoring it with Nagios or some other tool. These scripts are primarily responsible for ensuring that the files on the system are in a consistent state. That is the default attitude people should take, but with exceptions: - stopping daemons: if the maintainer scripts have to make some changes to data (e.g. changing a schema), they should not attempt to do so if the attempt to stop the daemon fails. In this case, the daemon should be stopped in the preinst of the new version of the package. If the preinst script can't stop the daemon it should abort. >> If it continues, is there any other convention for reporting the >> problem, e.g. stderr? > > You report errors and warnings to stderr, yes. For sysvinit there is a > shell API that can be used for that. Systemd might have its own > convention for unit files. > > A better way to get error/warning information to the user would be > welcome, but it needs to be properly planned (headless nodes, unattended > upgrades, desktops with crippled local mail delivery/routing, etc). > Thanks, I'm aware of the way the init scripts should use log_warning_msg and friends. I was only asking about any specific logging or reporting that the pre* and post* scripts should do, maybe that should also be mentioned in this section of the policy and included in the example.
Bug#802501: init script failures during postinst and related scripts
Package: debian-policy Severity: important If postinst or one of the other scripts does a service restart and the restart operation fails, should the postinst abort or should it mask the error, continue and return success? If it continues, is there any other convention for reporting the problem, e.g. stderr? Looking at s9.3.3 "Interfacing with the initscript system" https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 it doesn't explicitly state what should happen.
Bug#790949: conditional-restart from postinst and related scripts of plugin packages
Package: debian-policy Severity: important Some of this has been discussed in other bugs such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=60979 requesting an init script action for restart-only-if-running Consider the following: - package foo provides a daemon - package foo-plugin-bar provides the 'bar' plugin for 'foo' How should the foo-plugin-bar postrm work? Should it restart foo? Should it do a conditional restart? During dist-upgrade, can anything be done to ensure the service is not started by mistake by one of the postinst scripts until the other package has also been upgraded? In the policy manual, s9.3.3.2 Running initscripts, it is suggested to use: if which invoke-rc.d /dev/null 21; then invoke-rc.d package action else /etc/init.d/package action fi Could it be better to give a second example, how to restart only if already running: if which invoke-rc.d /dev/null 21; then invoke-rc.d status package /dev/null 21 \ invoke-rc.d package restart else /etc/init.d/package restart fi # whatever happened, return success: true Plugin packages, such as foo-plugin-bar, may want to use this second example or some variation of it instead. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55965461.9050...@pocock.pro
Bug#737559: copyright-format: author != copyright, add an author field?
Package: debian-policy Author and copyright holder are not always the same person/entity. E.g. the work may be authored by Bob but the copyright is assigned to his employer Acme, Inc, e.g. License: GPL2 Copyright: 2014, Acme, Inc http://acme.example.org Author: Bob, http://example.org/bob For cases where the License field contains the value public-domain and the name of the author is known, it is not appropriate to put the name in the license field, but it would be desirable to record the name of the author, e.g. License: public-domain Copyright: none Author: Bob, http://example.org/bob This may also reflect real-life situations where contributor license agreements require contributors to completely assign their intellectual property to some organisation (such as FSF) http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright Has this not already come up anywhere? I found a related bug that deals with part of the issue (must insert none in the Copyright field of public-domain) but that is not the whole issue, maybe they can be resolved together http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694883 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52efe2ab.9080...@pocock.com.au
Bug#737559: copyright-format: author != copyright, add an author field?
On 03/02/14 20:17, Jonathan Nieder wrote: severity 737559 wishlist user debian-pol...@packages.debian.org usertags 737559 = normative issue quit Hi Daniel, Daniel Pocock wrote: Author and copyright holder are not always the same person/entity. [...] License: GPL2 Copyright: 2014, Acme, Inc http://acme.example.org Author: Bob, http://example.org/bob Sure. A few thoughts: - I don't think debian/copyright needs to list everyone who contributed to the code --- to me, the copyright holders and some contact information for upstream seem more important, and the detailed authorship information can go elsewhere (e.g., a README or THANKS file, or the changelog). But policy's more ambiguous about that. See http://bugs.debian.org/678607. - The above is already valid syntax, since custom fields can be added to any paragraph. Feel free to try it and let us know how it goes. (copyright-format sayeth: No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. Future versions of the debian/copyright specification will attempt to avoid conflicting specifications for widely used extra fields. ) - Response when this last came up[1]: This is nice in spirit, but I would personnally not feel like maintaining a contributor list, because there is mostly only blame to get in case it is inaccurate, so I would only use the field to point at a contributors file. Just to clarify, I do not believe that maintaining this field should be obligatory It should be an optional field Defining it formally in the standard and having some examples will help emphasize the difference between what people should put in the Copyright field and what should not be there. If a maintainer feels that some author is particularly noteworthy or deserving, then they can put that author's name in the field even if the author has no entitlement to appear in the copyright field. This is the kind of field that I would prefer to see tested in real life before being standardised in DEP-5. So, I think this is a reasonable idea, and if more than two or so packages start using the field then it's probably worth documenting in policy to allow tools to start to consume it if they like. Thanks, Jonathan [1] https://lists.debian.org/debian-project/2010/07/msg00088.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52efec71.9060...@pocock.com.au
Bug#737559: copyright-format: author != copyright, add an author field?
On 03/02/14 20:55, Jonathan Nieder wrote: Daniel Pocock wrote: I've only come across one package which included public-domain material so far. In this case, I put a note about the author in the comments. Yep - that works, too. [...] One risk of not having this extra field is that we could accumulate excessive things in the Copyright field. E.g. some packagers may be including the names of contributors as if they are copyright holders because they are afraid their package will be queried (and subsequently delayed) by the FTP masters if they left something out by mistake. Hm. copyright-format already says one or more free-form copyright statements. [...] The Copyright field collects all relevant copyright notices for the files of this paragraph. It doesn't say anything about listing authors. It actually looks pretty clear. I agree it is reasonably clear While it is not Debian's fault and there is nothing we can do about it, there are upstreams who mix and match authors and copyright holders in their notices and there are others who consistently include the correct copyright notice in every file. Sometimes they distribute an AUTHORS file and in some cases, the people named in that file are entitled to be named in the Copyright field. In other cases, the people in the AUTHORS file or whatever have waived or assigned their rights. In the best cases these things are explained. The paragraph you quote above could well go on to say Not every author or contributor is a copyright holder. Only those listed in a Copyright line in the source should be included in the Copyright field. Names mentioned in an authors or contributors file or committers on the repository may not be copyright holders if there is an explicit copyright statement present. In the absence of an explicit copyright statement, those alternative mechanisms may be useful for ascertaining copyright. Maybe some ftp-master related documentation needs an update (e.g., perhaps the chain of links https://ftp-master.debian.org/ - REJECT-FAQ - this mail 87u09lawkj@vorlon.ganneff.de has been misleading people). In that case, I suspect a fix to bug#678607 (clarifying that there is no need for debian/copyright to list who wrote each line of code) would help. I don't think adding extra fields would save people from this source of worry. Adding the fields alone doesn't resolve the problem It is a communication issue and little things like this can help - I make no claim that this is some silver bullet and that if this field is added every copyright listing will become perfect There are cases where I would have used it and I believe that recognising people's work (even if they have assigned their rights) is an important way of showing our thanks and acknowledgment to those who develop free software, and having a dedicated field makes them stand out just that little bit more. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f000e5.9080...@pocock.com.au
Bug#737559: copyright-format: author != copyright, add an author field?
On 03/02/14 21:58, Russ Allbery wrote: Daniel Pocock dan...@pocock.com.au writes: There are cases where I would have used it and I believe that recognising people's work (even if they have assigned their rights) is an important way of showing our thanks and acknowledgment to those who develop free software, and having a dedicated field makes them stand out just that little bit more. I'm all in favor of recognizing people's work. I'm dubious that the *copyright* file is the right place to do that, for precisely the reason that you point out about why the Copyright field is the wrong place to do that. The copyright file in our packages is primarily a legal artifact, with some other stuff mixed in. It's not a model of purity of purpose at the moment (see other stuff mixed in), but I'm not sure that evolving it further in the direction of being a catch-all metadata file about the upstream code is a good idea. In other words, I think the author information might fit better into DEP-12 than in copyright-format. I agree that author/contributor info is not always relevant from a legal perspective On the other hand - it is the type of data that a maintainer will come across as they prepare the copyright file anyway - there are examples for using legal documents to acknowledge/credit people (e.g. the US regularly names laws after people) - sometimes the license text itself refers to both copyright holders AND contributors, e.g. I'm sure you are familiar with clauses like: 4. Neither the name of the organization nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the FreeBSD Project. These don't require us to name the authors/contributors, but as those people are referred to in the license text, their names are not completely irrelevant either. Obviously, I can get by just inserting names in the comments, I don't see any urgency to change the policy on this in the blink of an eye, but I hope it is useful feedback for the copyright policy and other related documents when they do come up for discussion again. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f00daa.40...@pocock.com.au
