Re: really? (Debian Policy and LSB)
Ah thanks. YEs that rings a bell now.
On 11/04/12 21:04, Raphael Hertzog wrote:
Hi,
On Wed, 11 Apr 2012, Nicholas Bamber wrote:
Hmm... This contradicts section 6.1 of the Debian policy.
"The package management system looks at the exit status from these
scripts. It is important that they exit with a non-zero status if
Here "these scripts" refer to "package maintainer scripts"
({pre,post}{inst,rm}) and not to "init scripts". So there's no
contradiction.
The problem of using "set -e" in init script is even documented
in policy 9.3.2:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init
| Be careful of using set -e in init.d scripts. Writing correct init.d
| scripts requires accepting various error exit statuses when daemons are
| already running or already stopped without aborting the init.d script, and
| common init.d function libraries are not safe to call with set -e in
| effect[72]. For init.d scripts, it's often easier to not use set -e and
| instead check the result of each command separately.
|
| [72] /lib/lsb/init-functions, which assists in writing LSB-compliant
| init scripts, may fail if set -e is in effect and echoing status messages
| to the console fails, for example.
Cheers,
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f85e540.7040...@periapt.co.uk
Re: really? (Debian Policy and LSB)
Hi,
On Wed, 11 Apr 2012, Nicholas Bamber wrote:
> Hmm... This contradicts section 6.1 of the Debian policy.
>
> "The package management system looks at the exit status from these
> scripts. It is important that they exit with a non-zero status if
Here "these scripts" refer to "package maintainer scripts"
({pre,post}{inst,rm}) and not to "init scripts". So there's no
contradiction.
The problem of using "set -e" in init script is even documented
in policy 9.3.2:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init
| Be careful of using set -e in init.d scripts. Writing correct init.d
| scripts requires accepting various error exit statuses when daemons are
| already running or already stopped without aborting the init.d script, and
| common init.d function libraries are not safe to call with set -e in
| effect[72]. For init.d scripts, it's often easier to not use set -e and
| instead check the result of each command separately.
|
| [72] /lib/lsb/init-functions, which assists in writing LSB-compliant
| init scripts, may fail if set -e is in effect and echoing status messages
| to the console fails, for example.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120411200431.gg16...@rivendell.home.ouaza.com
really? (Debian Policy and LSB)
tag 621020 +moreinfo thanks Regarding #621020 "/etc/init.d/mysql uses "set -e" for most of the script, but that is not compatible with the LSB library /lib/lsb/init-functions. This particularly causes problems whenever log_end_msg is called with a nonzero argument, as log_end_msg will return that argument and halt the script. So there are several chunks of code that will never be called (some informational messages and the stop-using-kill bit)." Hmm... This contradicts section 6.1 of the Debian policy. "The package management system looks at the exit status from these scripts. It is important that they exit with a non-zero status if there is an error, so that the package management system can stop its processing. For shell scripts this means that you almost always need to use set -e (this is usually true when writing shell scripts, in fact). It is also important, of course, that they exit with a zero status if everything went well." Copying "debian-devel" for more general comments. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f85dd6c.6020...@periapt.co.uk
Re: The future of non-dependency-based boot
On Wed, 11 Apr 2012, Raphael Hertzog wrote:
> On Wed, 11 Apr 2012, Brian May wrote:
> > On 10 April 2012 16:06, Yves-Alexis Perez wrote:
> > >> dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
> > >>
> > > That's a pretty dangerous line. People (sometimes) don't purge packages
> > > for a reason, you might lose data here.
> >
> > Under some circumstances it can delete configuration files that are in
> > use by active packages.
> >
> > e.g. package b replaces package a, however uses the same set of
> > configuration files - purge package a and it will delete the
> > configuration
> > files now in use by package b.
>
> Err, no. At least dpkg shouldn't do that. If you can reproduce it, please
> file a bug.
AFAIK, the problem is not a conffile (dpkg-managed), but config
files/directories and runtime data files/directories that are destroyed
by the postrm script in "package a" when it is purged.
> (Make sure it's not some postrm that is badly behaving)
That is exactly the problem. And the usual safe way to deal with it is
manually inspect every postrm script, and rm/edit it when necessary
before purguing the package. It is damn obvious why most of us prefer
to leave "package a" to rot in "removed-but-not-purged" state forever,
or at least until it causes some problem...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120411172725.ga8...@khazad-dum.debian.net
Bug#668413: ITP: libcgi-compile-perl -- module for compiling .cgi scripts to a code reference
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcgi-compile-perl Version : 0.15 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/CGI-Compile/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for compiling .cgi scripts to a code reference CGI::Compile is an utility to compile CGI scripts into a code reference that can run many times on its own namespace, as long as the script is ready to run on a persistent environment. NOTE: for best results, load CGI::Compile before any modules used by your CGIs. Combined with CGI::Emulate::PSGI, your CGI script can be turned into a persistent PSGI application. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120411172415.ga4...@jadzia.comodo.priv.at
Bug#664257: multiarch tuples are not documented/defined
On Sat, Mar 17, 2012 at 07:03:09AM +0100, Matthias Klose wrote: >Package: general >Severity: serious >Tags: wheezy, sid > >While we strive to get multiarch ready for squeeze, there is >currently nothing to point to what the multiarch tuples actually >mean, neither on the Debian side nor on some kind of standards side >like the FHS or LSB. This has to be documented on the Debian side, >and better be incorporated into standards like the FHS or LSB. > >The current state is http://wiki.debian.org/Multiarch/Tuples, >deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An >email to debian-ports didn't get any feedback. From my point of view >such a wiki page should be self-contained and be usable as a >reference for upstream projects. My current concern is that upstream >builds of GCC and binutils are currently broken and patch submissions >to GCC are on hold until such a definition is available at least on >the Debian side. I've updated http://wiki.debian.org/Multiarch/Tuples with lots more information such as links to external ABI specs where I could find them. I based this on Jonathan Nieder's initial email (thanks!) and filled in from there. For the non-Linux ports a bit more help would be useful; I don't know where the Hurd/kFreeBSD ports are specified externally, if indeed they are at all. Review/comments/corrections welcome. I hope this helps with what you're looking for, Matthias? -- Steve McIntyre, Cambridge, UK.st...@einval.com "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120411170035.gi21...@einval.com
Re: The future of non-dependency-based boot
[Sven Joachim] > I beg to disagree, it is already unsupportable because the only way > to test it is to set up a lenny system, create some local init > script without LSB headers to prevent migration to dependency based > boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flbomyqlr6@login1.uio.no
Re: The future of non-dependency-based boot
On Wednesday, April 11, 2012 05:14:34, Thomas Goirand wrote: > On 04/11/2012 06:12 AM, Chris Knadle wrote: > > - if the init script left behind was part of a Debian package, deleting > > the init script means removing part of the configuration from the Debian > > pacakge, yet not purging the package it belongs to. This feels like > > something that would volate Debian policy regarding one package not > > altering the configuration of another. > > Likewise, moving the init script means that purging the old package > > that had configuration left behind will no longer delete the init > > script file, which will thus be left behind as orphaned cruft. > > You do realize that we are talking about leftovers from Etch (and > possibly earlier) in Wheezy, which means 4 or 5 years later, right? I don't disagree that the leftovers are old (whether it be from lenny or older)... but will the upgrade script check this? [Presumably the upgrade script would normally only check if the init script is dependency-based compatible, and not how old the init script is or whether it's associated with a Debian package.] > If you think that we can't delete them, how about moving them > away in a special folder, like /etc/init.d/obsolete-scripts (feel free > to propose a better name for that folder)? We could prompt the > user about them, so he wont miss it, and the "configuration" that > you are talking about will stay (even though, most likely, this is > quite useless, IMO). I think I agree with this proposition at least in spirit [I'm all for fixing the problem, afterall :-P], but I'm wondering whether this is the right thing to do or if there's maybe a better alternative. Personally, I'd rather give the user an option to purge the associated package the init script is in (if it's in one), especially if the package has been removed-but-not-purged. If that could be accomplished I think that would be a cleaner way of dealing with the problem. I think another option (which maybe could be used as a fallback) would be to leave the broken init script in place, but to 'chmod -x' the file to make it non-executable. [Would this work within the dependency-based framework?] > > - the upgrade may be unattended or automatic, in which case presumably > > the default will be chosen and the user/admin will never know that the > > init script was removed, so the default of 'yes' is dangerous. > > The default with "no" may be even more dangerous. If you run in a > non-interactive way, then you will still have some non-LSB header scripts > on the way, which may prevent you from booting. I'm trying to figure out a way this can be handled which will conform to Debian Policy section 6.3. Link for convenience: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s- controllingterminal Between us both, I think we've found that there's a problem with either default, which means this is going to be tricky to handle. :-/ > > - the current administrator at the keyboard may not be the one that > > wrote or installed the custom-installed init script, so the upgrade may > > need to be completed before the question of whether the init script can > > be deleted has a satisfactory answer, but an answer of 'no' will > > presumably cause an issue for dependency-based bootup. > > If we move the *bad* scripts away in a specific folder, we have best of > both worlds, IMO. > > Thoughts? It's better than deletion, but I'd also like to consdier alternatives. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#639214: Find aa paartner aand get laaid t0night!x
Find aa paartner aand get laaid t0night!x https://docs.google.com/document/d/159mFk7o0zdB7WGup7dpCC_cYqDIuQbKTe7cF4X96iQw/edit - To stop rexceiving mesxsages from us pleasxe send an email to oeqz0215 [at] gmail [dot] com with the worxd REMOVE in the suxbject line. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120411102511.19...@web004.nyc1.bluetie.com
Re: The future of non-dependency-based boot
On 2012-04-11 12:13 +0200, Goswin von Brederlow wrote: > 2) Static order is currently supported and supporting it for wheezy > doesn't incurr horrible amounts of work. I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx6iwm9f@turtle.gmx.de
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote: > Roger Leigh writes: > As a side note I have a use case at work where static order seems to be > needed. We build boot images for network boot of clusters. During boot > additional files can be copied from NFS into the system including boot > scripts. When using dependency based boot order the numbers for boot > scripts change a lot depending on the boot image (include support for > lustre, ha, slurm, ... and each gets a different order). That makes it > impossible (or at least a lot harder) to copy in the same generic boot > scripts from NFS into different images since the name needs to be > different for each case. The boot scripts would have to be reordered > during boot. So do your boot scripts declare the correct dependency information in the LSB header? With dependency based boot, the numbers are meaningless other than for ordering. The fact that they change is to be expected. Are you running insserv to update the ordering? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120411102751.ga...@codelibre.net
Re: The future of non-dependency-based boot
Roger Leigh writes: > Hi, > > When dependency-based booting was introduced, it was initially > entirely optional. We later made it the default, and encouraged > users to switch to dependency-based boot on upgrade. So today, > pretty much everyone will be using dependency-based boot with > there being a minority continuing to use the static boot ordering > of yore. Probably mostly users who upgraded from etch. > > The reason for this mail is mainly to ask if there is any > continuing need for the old static ordering to be kept, and if > not, how best to migrate the remaining users. With all other > init systems worth their salt requiring dependencies, should > sysvinit not do the same? > > Now that all (?) init scripts provide LSB headers, the existing > static ordering will increasingly bitrot. It was never that great > to begin with, but with dependency ordering being used by the vast > majority, it's going to be increasingly untested. Do we want to > continue to maintain something that will be increasingly > unsupportable, or complete the migration cleanly before that point? > > WRT actually doing this, the main issues I can see are > - blocking by obsolete-but-unpurged init scripts without LSB header. > We could mv them out of the way to .dpkg-old and continue, or > abort and require manual intervention. > - breakage of any non-LSB scripts remain after this. We could > abort in the preinst and prevent upgrade until it's manually > resolved, unless there's a cleaner way to handle it. > Obviously, we don't want to make any systems unbootable, but doing > it without any manual intervention where possible would be > desirable. > > This can, of course, be left until wheezy+1. It's just something > which needs considering before it becomes a bigger problem. > > > Regards, > Roger I think: 1) Long term the init situation will change anyway with upstream / systemd rising in popularity. But not in wheezy. So why not wait for that before dropping existing support. 2) Static order is currently supported and supporting it for wheezy doesn't incurr horrible amounts of work. It hasn't degraded enough to warrant removing it yet. 3) Aborting the upgrade because dependency boot ordering fails will be a major issue for users. You already mentioned 2 issues and on my system at home I get an error about a dependency loop. Dependency based boot doesn't seem to be universally working enough yet. Conclusion: Given the short timeframe for wheezy keep things as they are. Consider removing it in wheezy+1. As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871unuefuy.fsf@frosties.localnet
Re: The future of non-dependency-based boot
On 04/11/2012 06:12 AM, Chris Knadle wrote: > - if the init script left behind was part of a Debian package, deleting the > init script means removing part of the configuration from the Debian pacakge, > yet not purging the package it belongs to. This feels like something that > would volate Debian policy regarding one package not altering the > configuration of another. > Likewise, moving the init script means that purging the old package that > had > configuration left behind will no longer delete the init script file, which > will thus be left behind as orphaned cruft. > You do realize that we are talking about leftovers from Etch (and possibly earlier) in Wheezy, which means 4 or 5 years later, right? If you think that we can't delete them, how about moving them away in a special folder, like /etc/init.d/obsolete-scripts (feel free to propose a better name for that folder)? We could prompt the user about them, so he wont miss it, and the "configuration" that you are talking about will stay (even though, most likely, this is quite useless, IMO). > - the upgrade may be unattended or automatic, in which case presumably the > default will be chosen and the user/admin will never know that the init > script > was removed, so the default of 'yes' is dangerous. > The default with "no" may be even more dangerous. If you run in a non-interactive way, then you will still have some non-LSB header scripts on the way, which may prevent you from booting. > - the current administrator at the keyboard may not be the one that wrote > or > installed the custom-installed init script, so the upgrade may need to be > completed before the question of whether the init script can be deleted has a > satisfactory answer, but an answer of 'no' will presumably cause an issue for > dependency-based bootup. > If we move the *bad* scripts away in a specific folder, we have best of both worlds, IMO. Thoughts? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f854b7a.8010...@debian.org
