Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-05-03 Thread Dmitry Bogatov
[2019-05-01 13:25] Alessandro Vesely > Put it another way, if I drop the (admittedly unrealistic) possibility > to edit rc?.d's by hand, I would have to conclude that that > architecture is a relic devoid of its functionality. Do we maintain > it for aesthetic reasons, like the Colosseum? > I

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-05-01 Thread Alessandro Vesely
On Thu 25/Apr/2019 16:12:42 +0200 Dmitry Bogatov wrote: > [2019-04-22 19:07] Alessandro Vesely > >> The point is building every time from scratch, rigidly enjoining specs, >> like it or lump it, versus an incremental, tolerant, minimal changes >> operation. > > What is the point of

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-25 Thread Dmitry Bogatov
[2019-04-22 19:07] Alessandro Vesely > > On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > > I agree, better not to break things if we don't need to, but introducing > > complexity to support broken setup? > I thought that script was way less complex than insserv... Hm, seems I was

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-22 Thread Alessandro Vesely
On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > [2019-04-18 18:30] Alessandro Vesely >> On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: >>> >>> But I think the current behaviour of insserv in this situation is to >>> bomb out completely and refuse to operate, isn't it ? So it

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-22 Thread Dmitry Bogatov
[2019-04-18 18:30] Alessandro Vesely > On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > > Dmitry Bogatov writes: > >> > >> As far as I know, "A depends B, B depends A" situation is called > >> RC-critical bug. > > > > If shipped by Debian but it can perhaps arise due to old packages, >

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-18 Thread Alessandro Vesely
On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > Dmitry Bogatov writes: >> >> As far as I know, "A depends B, B depends A" situation is called >> RC-critical bug. > > If shipped by Debian but it can perhaps arise due to old packages, > ad-hoc packages, etc. I agree that it's wrong but

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-18 Thread Alessandro Vesely
On Thu 18/Apr/2019 12:24:25 +0200 Dmitry Bogatov wrote: > [2019-04-17 18:02] Alessandro Vesely >> >> I recall having seen all links renumbered as 01, 02, 03, ... On the machine >> I'm writing from now --a client where the boot sequence was never tampered >> with-- links are numbered with gaps.

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-18 Thread Ian Jackson
Dmitry Bogatov writes ("Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable"): > [2019-04-17 18:02] Alessandro Vesely > > I just meant respecting the existing order, either if possible or if a fix > > is > > not at all obvious. Supp

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-18 Thread Dmitry Bogatov
[2019-04-17 18:02] Alessandro Vesely > On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > > Right now insserv implements little more than topological sort. You can > > modify relations between scripts by editing LSB headers. What do you > > mean 'adjusting links without subverting

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-17 Thread Alessandro Vesely
On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > [2019-04-15 09:14] Alessandro Vesely >> >> Nowadays, stable sort algorithms are really widespread. Adjusting links >> without subverting their existing order is not that hard. > > I am not going to implement it, but even as user I fail

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-16 Thread Dmitry Bogatov
[2019-04-15 09:14] Alessandro Vesely > I get this: > insserv: There is a loop between service umountnfs and rsyslog if stopped > insserv: loop involving service rpcbind at depth 3 > insserv: loop involving service umountnfs at depth 2 > insserv: loop involving service gdm3 at depth 1 >

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-15 Thread Alessandro Vesely
On Sun 14/Apr/2019 12:52:44 +0200 Dmitry Bogatov wrote: > > control: tags -1 +wontfix +moreinfo > > [2019-04-11 10:54] Jesse Smith When update-rc.d calls insserv, the rcN.d directories are rebuilt without taking into consideration any adjustment that might have been set up

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-14 Thread Dmitry Bogatov
control: tags -1 +wontfix +moreinfo [2019-04-11 10:54] Jesse Smith > >> When update-rc.d calls insserv, the rcN.d directories are rebuilt > >> without taking into consideration any adjustment that might have > >> been set up locally. That seems to be done on the assumption that > >> the

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

2019-04-11 Thread Jesse Smith
>> When update-rc.d calls insserv, the rcN.d directories are rebuilt >> without taking into consideration any adjustment that might have >> been set up locally. That seems to be done on the assumption that >> the dependencies coded in the LSB blocks are universally accurate. >> Now, LSBs are a

Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

2019-04-11 Thread Dmitry Bogatov
control: tags -1 +moreinfo [2013-06-10 13:53] Alessandro Vesely > When update-rc.d calls insserv, the rcN.d directories are rebuilt > without taking into consideration any adjustment that might have > been set up locally. That seems to be done on the assumption that > the dependencies coded

Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

2013-06-10 Thread Alessandro Vesely
Package: insserv Version: 1.14.0-5 Severity: normal When update-rc.d calls insserv, the rcN.d directories are rebuilt without taking into consideration any adjustment that might have been set up locally. That seems to be done on the assumption that the dependencies coded in the LSB blocks are