Re: dh_installinit: what to do if upstream provides a initscript?
On 01/07/2010 06:52 PM, Russ Allbery wrote: Darshaka Pathirana d...@syn-net.org writes: I have the following situation: I have a upstream-package which provides an init.d-script. dh_installinit(1) states: , | If a file named debian/package.init exists, then it is installed into | etc/init.d/package in the package build directory, with package | replaced by the package name. ` So here the simple question (for which I could not find a simple answer): What to do if upstream already provides an init-script? Am I supposed to copy the init-script into the debian directory or is there a better solution to avoid double-handling the file? dh_installinit will just do the maintainer script modifications if there is no package.init file. You can use whatever other mechanism works (such as the upstream make install rule, if it does the right thing) to install the init script into the Debian packaging area. I am sorry for bugging you but the answer is again RTFM. dh_installinit(1): , |-o, --onlyscripts |Only modify postinst/postrm/prerm scripts, do not actually install |any init script or default files. May be useful if the init script |is shipped and/or installed by upstream in a way that doesn’t make |it easy to let dh_installinit find it. ` Must have had not enough sleep and/or not enough coffee. ;) Thank you! Regards, - Darsha -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh_installinit: what to do if upstream provides a initscript?
On Fri, Jan 08, 2010 at 02:56:56PM +0100, Darshaka Pathirana wrote: , |-o, --onlyscripts |Only modify postinst/postrm/prerm scripts, do not actually install |any init script or default files. May be useful if the init script |is shipped and/or installed by upstream in a way that doesn’t make |it easy to let dh_installinit find it. ` Must have had not enough sleep and/or not enough coffee. ;) I'll put that into the newmaint guide, it's a small enough thing but could catch people. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh_installinit: what to do if upstream provides a initscript?
Darshaka Pathirana d...@syn-net.org writes: I have the following situation: I have a upstream-package which provides an init.d-script. dh_installinit(1) states: , | If a file named debian/package.init exists, then it is installed into | etc/init.d/package in the package build directory, with package | replaced by the package name. ` So here the simple question (for which I could not find a simple answer): What to do if upstream already provides an init-script? Am I supposed to copy the init-script into the debian directory or is there a better solution to avoid double-handling the file? dh_installinit will just do the maintainer script modifications if there is no package.init file. You can use whatever other mechanism works (such as the upstream make install rule, if it does the right thing) to install the init script into the Debian packaging area. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh_installinit...
On Tue, May 18, 2004 at 08:43:40AM -0700, Matt Zimmerman wrote: On Mon, May 10, 2004 at 04:20:18PM +0200, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). Have an /etc/default/camsource where the admin has to enable the daemon setting $START_CAMSOURCE? The init script could display something like Please configure camsource using /etc/camsource.conf and enable it in /etc/default/camsource if you want to use init to start it. if not enabled... Use --no-start with dh_installinit and stop the daemon manually on uninstall in prerm? Other? Let it fail to start; simply don't allow this to break the postinst. Okay, after fiddling around a little and not being sure what solution I'd prefer I go for Matt's. To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). My idea is to set a variable in postinst that the initscript can check. This works fine so far, but is there an existing variable I could use for a cleaner solution? -- Balu
Re: dh_installinit...
On Thu, 2004-06-17 at 13:48, Thomas -Balu- Walter wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Don't try to control the exit status with an environment variable. Let the initscript return a nonzero status. If you need to ignore the status (because you have set -e) then append '|| :' to the line that returns the error status. $ false || : $ echo $? 0 -- Thomas
Re: dh_installinit...
Thomas -Balu- Walter [EMAIL PROTECTED] wrote: On Tue, May 18, 2004 at 08:43:40AM -0700, Matt Zimmerman wrote: Let it fail to start; simply don't allow this to break the postinst. Okay, after fiddling around a little and not being sure what solution I'd prefer I go for Matt's. To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dh_installinit...
On Thu, Jun 17, 2004 at 02:04:52PM +0200, Thomas Hood wrote: Don't try to control the exit status with an environment variable. Let the initscript return a nonzero status. If you need to ignore the status (because you have set -e) then append '|| :' to the line that returns the error status. You got me a little wrong. This is what I want to do, but I do not want the initscript to return a nonzero status all the time. An error status code returned by the init script is a very nice feature e.g. if an admin starts the script manually he might want to check the status code. Making it return a nonzero status code all the time is a bad idea because of this. However - my problem is that the start of the daemon might fail (because a video device is not attached e.g.) during postinst. This failure should not break the postinst but simply display a message or similar. So I put the following into the start segment of the init script: if [ $RUNNING_IN_POSTINST = 1 ]; then start-stop-daemon --start --quiet --chuid camsource:video \ --exec $DAEMON || \ echo Please make sure that a video device exists or\ configure camsource to use a different source. else start-stop-daemon --start --quiet --chuid camsource:video \ --exec $DAEMON fi $RUNNING_IN_POSTINST is set in postinst then and will start the daemon, but return a non-error status code and print a message. The problem then will not break postinst. If $RUNNING_IN_POSTINST is not set - the daemon gets started as it should be and returns the correct error code. My question is just if there is a variable I can check that already exists in contrast to creating my own $RUNNING_IN_POSTINST. -- Balu
Re: dh_installinit...
On Thu, Jun 17, 2004 at 02:25:35PM +0200, Frank Küster wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Because I do not want to install, configure, etc. the initscript manually in postinst. I simply use dh_installinit as helper which will also work if the init-procedure changes somehow or something like this. -- Balu
Re: dh_installinit...
Thomas -Balu- Walter [EMAIL PROTECTED] schrieb: On Thu, Jun 17, 2004 at 02:25:35PM +0200, Frank Küster wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Because I do not want to install, configure, etc. the initscript manually in postinst. I simply use dh_installinit as helper which will also work if the init-procedure changes somehow or something like this. I understand you that you prefer it this way. But unless dh_installinit has a --true-if-fail option, you should do it manually in this case. Fiddling with this variable stuff in POSTINST isn't really easier than writing manual invoke-rc.d calls into your postinst. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dh_installinit...
On Tue, May 18, 2004 at 08:43:40AM -0700, Matt Zimmerman wrote: On Mon, May 10, 2004 at 04:20:18PM +0200, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). Have an /etc/default/camsource where the admin has to enable the daemon setting $START_CAMSOURCE? The init script could display something like Please configure camsource using /etc/camsource.conf and enable it in /etc/default/camsource if you want to use init to start it. if not enabled... Use --no-start with dh_installinit and stop the daemon manually on uninstall in prerm? Other? Let it fail to start; simply don't allow this to break the postinst. Okay, after fiddling around a little and not being sure what solution I'd prefer I go for Matt's. To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). My idea is to set a variable in postinst that the initscript can check. This works fine so far, but is there an existing variable I could use for a cleaner solution? -- Balu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit...
On Thu, 2004-06-17 at 13:48, Thomas -Balu- Walter wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Don't try to control the exit status with an environment variable. Let the initscript return a nonzero status. If you need to ignore the status (because you have set -e) then append '|| :' to the line that returns the error status. $ false || : $ echo $? 0 -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit...
Thomas -Balu- Walter [EMAIL PROTECTED] wrote: On Tue, May 18, 2004 at 08:43:40AM -0700, Matt Zimmerman wrote: Let it fail to start; simply don't allow this to break the postinst. Okay, after fiddling around a little and not being sure what solution I'd prefer I go for Matt's. To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dh_installinit...
On Thu, Jun 17, 2004 at 02:04:52PM +0200, Thomas Hood wrote: Don't try to control the exit status with an environment variable. Let the initscript return a nonzero status. If you need to ignore the status (because you have set -e) then append '|| :' to the line that returns the error status. You got me a little wrong. This is what I want to do, but I do not want the initscript to return a nonzero status all the time. An error status code returned by the init script is a very nice feature e.g. if an admin starts the script manually he might want to check the status code. Making it return a nonzero status code all the time is a bad idea because of this. However - my problem is that the start of the daemon might fail (because a video device is not attached e.g.) during postinst. This failure should not break the postinst but simply display a message or similar. So I put the following into the start segment of the init script: if [ $RUNNING_IN_POSTINST = 1 ]; then start-stop-daemon --start --quiet --chuid camsource:video \ --exec $DAEMON || \ echo Please make sure that a video device exists or\ configure camsource to use a different source. else start-stop-daemon --start --quiet --chuid camsource:video \ --exec $DAEMON fi $RUNNING_IN_POSTINST is set in postinst then and will start the daemon, but return a non-error status code and print a message. The problem then will not break postinst. If $RUNNING_IN_POSTINST is not set - the daemon gets started as it should be and returns the correct error code. My question is just if there is a variable I can check that already exists in contrast to creating my own $RUNNING_IN_POSTINST. -- Balu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit...
On Thu, Jun 17, 2004 at 02:25:35PM +0200, Frank Küster wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Because I do not want to install, configure, etc. the initscript manually in postinst. I simply use dh_installinit as helper which will also work if the init-procedure changes somehow or something like this. -- Balu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit...
Thomas -Balu- Walter [EMAIL PROTECTED] schrieb: On Thu, Jun 17, 2004 at 02:25:35PM +0200, Frank Küster wrote: To do so I need the initscript to make a difference if the package is called from postinst (don't exist with error status code) or not (exit with error status code to allow an admin to script something e.g.). Why this? Why not just invoke-rc.d $INITSCRIPT start || true Because I do not want to install, configure, etc. the initscript manually in postinst. I simply use dh_installinit as helper which will also work if the init-procedure changes somehow or something like this. I understand you that you prefer it this way. But unless dh_installinit has a --true-if-fail option, you should do it manually in this case. Fiddling with this variable stuff in POSTINST isn't really easier than writing manual invoke-rc.d calls into your postinst. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dh_installinit...
On Mon, May 10, 2004 at 04:20:18PM +0200, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). Have an /etc/default/camsource where the admin has to enable the daemon setting $START_CAMSOURCE? The init script could display something like Please configure camsource using /etc/camsource.conf and enable it in /etc/default/camsource if you want to use init to start it. if not enabled... Use --no-start with dh_installinit and stop the daemon manually on uninstall in prerm? Other? Let it fail to start; simply don't allow this to break the postinst. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit...
On Mon, 2004-05-10 at 11:20, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). I should think the normal case for a webcam (I'm thinking USB webcams, now) would be for the cam to not necessarily be present at boot time. Instead, when the cam module is loaded/unloaded by the kernel it should invoke via kernel module (un-)loading hooks the necessary scripts for starting/stopping the streaming server. Are you sure you really want this as an init script? Ben -- synrg at debian dot org
Re: dh_installinit...
On Mon, May 10, 2004 at 12:18:07PM -0300, Ben Armstrong wrote: On Mon, 2004-05-10 at 11:20, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). I should think the normal case for a webcam (I'm thinking USB webcams, now) would be for the cam to not necessarily be present at boot time. Instead, when the cam module is loaded/unloaded by the kernel it should invoke via kernel module (un-)loading hooks the necessary scripts for starting/stopping the streaming server. Are you sure you really want this as an init script? My sponsor wanted me to add one... :) My first package version was just the installed software with a sample configuration and a text describing how to set up and start it. BTW - it does not have to be a webcam. It could also stream your desktop e.g. depending on the module and how you configured it. -- Balu
Re: dh_installinit...
On Mon, May 10, 2004 at 12:18:07PM -0300, Ben Armstrong wrote: On Mon, 2004-05-10 at 11:20, Thomas -Balu- Walter wrote: I'm not sure what would be best practice to avoid those errors, because the admin might have to configure the video device first anyway (though the default /dev/video0 is usually a nice guess). I should think the normal case for a webcam (I'm thinking USB webcams, now) would be for the cam to not necessarily be present at boot time. Instead, when the cam module is loaded/unloaded by the kernel it should invoke via kernel module (un-)loading hooks the necessary scripts for starting/stopping the streaming server. Are you sure you really want this as an init script? My sponsor wanted me to add one... :) My first package version was just the installed software with a sample configuration and a text describing how to set up and start it. BTW - it does not have to be a webcam. It could also stream your desktop e.g. depending on the module and how you configured it. -- Balu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sat, Nov 09, 2002 at 12:06:58 -0500, Joey Hess wrote:
joey@dragon:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
--
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Of course debconf (dpkg-reconfigure) is needed at run time. Are you
confusing it with debhelper?
--
Robbe
signature.ng
Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: Since debconf 1.2.9 dpkg-reconfigure calls prerm, which does invoke-rc.d stop, so I think this would be the correct runtime dependency when dpkg-reconfigure has to stop a daemon before it can be (re)started in postinst... I don't see what you mean, and this seems to have nothing to do with your other, very strange suggestion that any package that uses dh_installinit needs to depend on debconf. Show me something breaking because of a missing dependency. -- see shy jo msg07811/pgp0.pgp Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Duh, I got debconf and debhelper mixed up. Never mind, a dependency is in
order.
--
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
Hi debian-mentors!
On Sun, 10 Nov 2002, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Duh, I got debconf and debhelper mixed up. Never mind, a dependency is in
order.
(replying to myself... I feel silly)
As long as it gets added only if you're using debconf... looks more like a
lintian/linda check waiting for someone to write it, than something
debhelper should do automatically.
--
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
On Sat, 09 Nov 2002, Martin Godisch wrote: On Sat, Nov 09, 2002 at 08:12:57 -0200, Henrique de Moraes Holschuh wrote: On Sat, 09 Nov 2002, Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Well, I once proposed people to use invoke-rc.d restart for that. It is (now) defined to be stop if it is running. Then start it. So you are suggesting not to use dh_installinit in this case and to write 'invoke-rc.d restart' manually into postinst? No. See Joey's reply. But you certainly _can_ do so if you wish. Should this be reported as a bug against debhelper? No :-) -- 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
Re: dh_installinit and dpkg-reconfigure
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sat, Nov 09, 2002 at 12:06:58 -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
--
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
Re: dh_installinit and dpkg-reconfigure
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Of course debconf (dpkg-reconfigure) is needed at run time. Are you
confusing it with debhelper?
--
Robbe
signature.ng
Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote:
On Sat, Nov 09, 2002 at 12:06:58 -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
Whatever for?
--
see shy jo
pgpIUpmeBPGZ5.pgp
Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: Since debconf 1.2.9 dpkg-reconfigure calls prerm, which does invoke-rc.d stop, so I think this would be the correct runtime dependency when dpkg-reconfigure has to stop a daemon before it can be (re)started in postinst... I don't see what you mean, and this seems to have nothing to do with your other, very strange suggestion that any package that uses dh_installinit needs to depend on debconf. Show me something breaking because of a missing dependency. -- see shy jo pgpw33R3hzMQZ.pgp Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Duh, I got debconf and debhelper mixed up. Never mind, a dependency is in
order.
--
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
Re: dh_installinit and dpkg-reconfigure
Hi debian-mentors!
On Sun, 10 Nov 2002, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know. There is no runtime dependency.
Duh, I got debconf and debhelper mixed up. Never mind, a dependency is in
order.
(replying to myself... I feel silly)
As long as it gets added only if you're using debconf... looks more like a
lintian/linda check waiting for someone to write it, than something
debhelper should do automatically.
--
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
Re: dh_installinit and dpkg-reconfigure
On Sat, 09 Nov 2002, Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Well, I once proposed people to use invoke-rc.d restart for that. It is (now) defined to be stop if it is running. Then start it. About 99% of the time a script is trying a start, it actually wants a stop if it is already there, then start it again... -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Make sure that your daemon is stopped for upgrade in the prerm. Which debhelper also does by default. -- see shy jo msg07789/pgp0.pgp Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: I do not upgrade, dpkg-reconfigure doesn't call prerm... Look again. joeydragon:~grep prerm =dpkg-reconfigure foreach my $info (['prerm','upgrade', $version], -- see shy jo msg07790/pgp0.pgp Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
On Sat, 09 Nov 2002, Martin Godisch wrote: On Sat, Nov 09, 2002 at 08:12:57 -0200, Henrique de Moraes Holschuh wrote: On Sat, 09 Nov 2002, Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Well, I once proposed people to use invoke-rc.d restart for that. It is (now) defined to be stop if it is running. Then start it. So you are suggesting not to use dh_installinit in this case and to write 'invoke-rc.d restart' manually into postinst? No. See Joey's reply. But you certainly _can_ do so if you wish. Should this be reported as a bug against debhelper? No :-) -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dpkg-reconfigure
On Sat, 09 Nov 2002, Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Well, I once proposed people to use invoke-rc.d restart for that. It is (now) defined to be stop if it is running. Then start it. About 99% of the time a script is trying a start, it actually wants a stop if it is already there, then start it again... -- 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
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to postinst, hence, after dpkg-reconfigure is run, postinst will try to start an already running service, start-stop-daemon will fail, and the daemon will not reload its new configuration. What's the correct way to handle this? Make sure that your daemon is stopped for upgrade in the prerm. Which debhelper also does by default. -- see shy jo pgpatvO6ykXXI.pgp Description: PGP signature
Re: dh_installinit and dpkg-reconfigure
Martin Godisch wrote: I do not upgrade, dpkg-reconfigure doesn't call prerm... Look again. [EMAIL PROTECTED]:~grep prerm =dpkg-reconfigure foreach my $info (['prerm','upgrade', $version], -- see shy jo pgp58jOS4Ok1X.pgp Description: PGP signature
Re: dh_installinit
Do a ./configure --help, examine the Makefile, etc. to find out what
variable it's using to determine the install path of the init script.
On another note, I've seen about half a dozen mails from you today on pretty
simple subjects. I suggest a more thorough reading of the new maintainer's
guide and other documents, as it's clear that you're still in the dark about
some things.
On Fri, Aug 03, 2001 at 11:20:06PM +0430, Pratik Sinha [EMAIL PROTECTED]
spake forth:
while packaging cups by defualt my the etc/init.d directory is getting
installed in /usr, what changes should i make to my rules file to avoid
this...
my rules file:
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.--
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# This is the debhelper compatability version to use.
export DH_COMPAT=1
configure: configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.
./configure --prefix=/usr --mandir=\$${prefix}/share/man\
--infodir=\$${prefix}/share/info \
--sbindir=\$${prefix}/sbin\
--bindir=\$${prefix}/bin \
--localstatedir=/var \
--sysconfdir=/etc
touch configure-stamp
build: configure-stamp build-stamp
build-stamp:
dh_testdir
# Add here commands to compile the package.
$(MAKE)
#/usr/bin/docbook-to-man debian/cups.sgml cups.1
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
-$(MAKE) distclean
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/tmp.
$(MAKE) install prefix=$(CURDIR)/debian/tmp/usr \
localstatedir=$(CURDIR)/debian/tmp/var \
sysconfdir=$(CURDIR)/debian/tmp/etc
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
# dh_testversion
dh_testdir
dh_testroot
# dh_installdebconf
dh_installdocs
dh_installexamples
dh_installmenu
# dh_installemacsen
# dh_installpam
dh_installinit
dh_installcron
dh_installmanpages
dh_installinfo
# dh_undocumented
dh_installchangelogs CHANGES.txt
dh_link
dh_strip
dh_compress
dh_fixperms
# You may want to make some executables suid here.
dh_suidregister
# dh_makeshlibs
dh_installdeb
# dh_perl
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
cheers
pratik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Mike Markley [EMAIL PROTECTED]
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084
Actual war is a very messy business. Very, very messy business.
- Kirk, A Taste of Armageddon, stardate 3193.0
Re: dh_installinit and dh_installkpatches questions.
Viral [EMAIL PROTECTED] wrote: Also, with dh_installinit, the init.d script gets a default priority of 20. How do I change it ? I tried dh_installinit -- defaults s90 k10 It makes the debs fine, but during installation, update-rc.d grumbles of bad parameters. Am I using the wrong syntax ? I'm using debhelper 3.0.19. You're slightly out: see update-rc.d(8). You probably want something more like: dh_installinit -- defaults 90 10 Cheers, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and dh_installkpatches questions.
Viral [EMAIL PROTECTED] wrote: Also, with dh_installinit, the init.d script gets a default priority of 20. How do I change it ? I tried dh_installinit -- defaults s90 k10 It makes the debs fine, but during installation, update-rc.d grumbles of bad parameters. Am I using the wrong syntax ? I'm using debhelper 3.0.19. You're slightly out: see update-rc.d(8). You probably want something more like: dh_installinit -- defaults 90 10 Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: dh_installinit and dh_installkpatches questions.
On Wed, May 23, 2001 at 12:18:18PM +0530, Viral wrote: Hi, I am packaging mosix, which is a cluster computing tool which does fault tolerance, load balancing and process migration. It comes as 2 kernel patches. One is a standard kernel patch which I handle with dh_installkpatches. The other is a tar file, which has to be untarred in /usr/src/linux. Can I handle this too with dh_installkpatches ? How otherwise would be a good way to do it ? Currently, I just have a note in README.Debian to do it manually. dh_installkpatches can't do this - does it have to be untarred? Why can't you just make up a diff, and apply that with dh_installkpatches? :) d BTW, for kernel-patch-ulog, there was no straight-out diff, so I had to apply it via patch-o-matic, and diff it against a clean source tree. -- Daniel Stone[EMAIL PROTECTED] [EMAIL PROTECTED]
