> "PR" == Petter Reinholdtsen 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 just t
]] 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 /etc/init.d/../
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 wo
]] 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 anywa
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.
>
[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 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 writes:
> > > [Sven Joachim]
> > >> I beg to disagree, it is already unsupportable because the only way
> > >> to test it is to set up a len
On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
> Petter Reinholdtsen 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 pre
Raphael Geissert 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
>> doesn't seem to
Petter Reinholdtsen 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 to squ
Roger Leigh writes:
> 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 copie
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
[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
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 obv
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, 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 packag
[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 inst
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 packa
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 ini
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 i
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
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 D
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.
>
> Un
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 f
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
> >> /et
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
>>
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
]] 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
Marco d'Itri wrote:
> On Apr 09, Roger Leigh 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 please.
> > WRT
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 a
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 debian
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 scri
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-quer
[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 Reinho
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
[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 Tue, Apr 10, 2012 at 11:55 AM, Jon Dowland 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).
Yes, it's a pi
On Tue, Apr 10, 2012 at 10:53 AM, Thomas Goirand 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 a huge warni
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 r
On 04/10/2012 07:03 AM, Marco d'Itri wrote:
> On Apr 09, Roger Leigh 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.
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 p
On Apr 09, Roger Leigh 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 main issues I can s
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
43 matches
Mail list logo
