PR == Petter Reinholdtsen p...@hungry.com writes:
PR You do not have to edit the init.d files themselves to override
PR their dependencies, and risk them going away during upgrades. I
PR created the possibility for the system administrator to insert
PR overrides in /etc/insserv/overrides/ for
[Roger Leigh]
I can't see why not at first glance--it's done its job, so should no
longer be needed.
It is still needed in two use cases.
1) Machine upgraded from Lenny where the migration was not done.
Either because it could not be done, or because the user choose
not to do it.
On Thu, Apr 19, 2012 at 09:01:55AM +0200, Petter Reinholdtsen wrote:
[Roger Leigh]
I can't see why not at first glance--it's done its job, so should no
longer be needed.
It is still needed in two use cases.
1) Machine upgraded from Lenny where the migration was not done.
Either
]] Roger Leigh
(I don't know if you saw my mail regarding having done this
provisionally in git; I mentioned it on the pkg-sysvinit-devel
list and in #545976. I was wanting to additionally ask you
how safe it would be to remove the is_unsafe_to_activate check
and just run insserv anyway,
On Thu, Apr 19, 2012 at 12:52:23PM +0200, Tollef Fog Heen wrote:
]] Roger Leigh
(I don't know if you saw my mail regarding having done this
provisionally in git; I mentioned it on the pkg-sysvinit-devel
list and in #545976. I was wanting to additionally ask you
how safe it would be to
]] Roger Leigh
Could you provide examples please? If there are init scripts which
it can't handle, that's a bug. Either in insserv or (more likely)
the scripts.
It fails to handle the case where something provides a virtual facility,
at least. It also seems to think that
Roger Leigh rle...@codelibre.net writes:
On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net 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
Petter Reinholdtsen p...@hungry.com writes:
[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
Raphael Geissert geiss...@debian.org writes:
Goswin von Brederlow wrote:
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
On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
Petter Reinholdtsen p...@hungry.com writes:
[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
On Wed, Apr 18, 2012 at 07:15:48PM +0200, Philipp Kern wrote:
On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
Petter Reinholdtsen p...@hungry.com writes:
[Sven Joachim]
I beg to disagree, it is already unsupportable because the only way
to test it is to set up a
Three notes:
Manually choosing the order remains a reasonable choice for many
servers. The upstream dependencies are not always sufficiently detailed
and edits to the init files can be lost when upgrading. Such servers
generally start only a few services and hand-tuning the order is easy
and
[James Cloos]
Manually choosing the order remains a reasonable choice for many
servers. The upstream dependencies are not always sufficiently detailed
and edits to the init files can be lost when upgrading.
Your assumptions are wrong. You do not have to edit the init.d files
themselves to
Le 15/04/2012 11:34, Petter Reinholdtsen a écrit :
[James Cloos]
Manually choosing the order remains a reasonable choice for many
servers. The upstream dependencies are not always sufficiently detailed
and edits to the init files can be lost when upgrading.
Your assumptions are wrong.
Goswin von Brederlow wrote:
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.
On Wed, 11 Apr 2012, Brian May wrote:
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org 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.
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
Roger Leigh rle...@codelibre.net 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
On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net 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
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
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
[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
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 cor...@debian.org 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
On mar., 2012-04-10 at 01:03 +0200, Marco d'Itri wrote:
Or just say in the release notes that it's a good idea to run something
like this before upgrading:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge
On 04/10/2012 07:03 AM, Marco d'Itri wrote:
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
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?
On 10/04/12 10:53, Thomas Goirand wrote:
I wholeheartedly agree.
I also agree that wheezy would be the correct moment to do it, and
that we shouldn't wait until wheezy+1.
I was hesitant to suggest that investing energy into improving the
current init system, if it is likely to be wholesale
On Tue, Apr 10, 2012 at 10:53 AM, Thomas Goirand z...@debian.org wrote:
Considering that most (if not all) scripts would be user custom-scripts,
I'd say that the best way would be to, just move them away on a special
folder, and execute them one by one, without any particular order, and
print
On Tue, Apr 10, 2012 at 11:55 AM, Jon Dowland j...@debian.org wrote:
I was hesitant to suggest that investing energy into improving the
current init system, if it is likely to be wholesale replaced, might
not be worthwhile (when that same energy could be put into hastening
the inevitable).
[Moray Allan]
With similar intention, I wondered about the possibility of running
scripts without the LSB headers after everything else. (= implied
dependency on those with LSB headers)
The intention of the current implementation is to assume such scripts
depend on $syslog and $remote_fs,
On Mon, Apr 09, 2012 at 10:26:38PM +0100, Roger Leigh wrote:
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
[Adam Borowski]
Am I supposed to fetch a copy of initscripts and manually compare
scripts it ships with those on 'dpkg -L initscripts'? Or is there
some other obscure way?
Try this one instead:
dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
--
Happy hacking
Petter
On Tue, Apr 10, 2012 at 05:16:36PM +0200, Petter Reinholdtsen wrote:
[Adam Borowski]
Am I supposed to fetch a copy of initscripts and manually compare
scripts it ships with those on 'dpkg -L initscripts'? Or is there
some other obscure way?
Try this one instead:
dpkg-query -W
On Tue, Apr 10, 2012 at 02:27:35PM +0200, Petter Reinholdtsen wrote:
As Debian should support init.d scripts as long as the Linux Software
Base require it, I believe it is worth spending some time making sure
init.d scripts work properly in Debian.
The LSB requires support for LSB init
Who said LSB requires insserv ? verify this. Um ... LSB requires everything I write too ! :)
Riight???!
But innserv makes a good effort to be compatible - so that end should be ok.
The LSB requires support for LSB init scripts; LSB init scripts have LSB
--
To UNSUBSCRIBE, email to
On Tuesday, April 10, 2012 05:53:48 PM Thomas Goirand wrote:
...
WRT actually doing this, the main issues I can see are
I say just abort the upgrade and let root deal with the issues found,
it's better than risking clobbering some local change.
Considering that most (if not all)
Marco d'Itri wrote:
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
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?
Kill it. With fire.
Yes
]] Adam Borowski
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
/etc/init.d/stop-bootlogd would provide the user with straightforward info
of what needs to be done.
I think this should just be
On Tue, Apr 10, 2012 at 10:44:36PM +0200, Tollef Fog Heen wrote:
]] Adam Borowski
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
/etc/init.d/stop-bootlogd would provide the user with
On 10.04.2012 22:44, Tollef Fog Heen wrote:
]] Adam Borowski
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
/etc/init.d/stop-bootlogd would provide the user with straightforward info
of what
On Wed, Apr 11, 2012 at 12:31:11AM +0200, Michael Biebl wrote:
On 10.04.2012 22:44, Tollef Fog Heen wrote:
]] Adam Borowski
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org 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
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
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
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?
Kill it. With fire.
WRT actually doing this, the
43 matches
Mail list logo
