Re: Upstart and sysvinit in packages - Policy needed
[Marco Amadori] I think it would be interesting for wheezy to easely permit an Admin to choose an alternate init system Sound like a good idea, if it do not give the Debian project a lot of unneeded work. and to permit to package maintainer to carefully provide init script tailored for a particular system of interest. Personally, I believe it the last point is a bad idea. Asking package maintainers to provide boot setup for several boot systems is going to leave some of these setups to slowly decay as only the one used by the package maintainer will get proper testing. I believe we need to come up with a way where most or all package maintainers (perhaps those handling kernel events and early boot stuff should be expected) only need to maintain one boot setup for their package, and this boot setup should be used by all the different boot systems. 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/2fl62smkc42@login2.uio.no
Re: Upstart and sysvinit in packages - Policy needed
Hi, Am Montag, den 14.02.2011, 13:57 +0100 schrieb Petter Reinholdtsen: I believe we need to come up with a way where most or all package maintainers (perhaps those handling kernel events and early boot stuff should be expected) only need to maintain one boot setup for their package, and this boot setup should be used by all the different boot systems. a way like metainit? http://wiki.debian.org/MetaInit The project died some two or three years ago and anyone is welcome to try to revive it. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Upstart and sysvinit in packages - Policy needed
]] Petter Reinholdtsen | I believe we need to come up with a way where most or all package | maintainers (perhaps those handling kernel events and early boot stuff | should be expected) only need to maintain one boot setup for their | package, and this boot setup should be used by all the different boot | systems. That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I don't believe there's a 1:1 correspondence between the semantics of all the different init systems, making this a very hard if not impossible job. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87y65iel60@qurzaw.varnish-software.com
Re: Upstart and sysvinit in packages - Policy needed
On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Petter Reinholdtsen | I believe we need to come up with a way where most or all package | maintainers (perhaps those handling kernel events and early boot stuff | should be expected) only need to maintain one boot setup for their | package, and this boot setup should be used by all the different boot | systems. That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I Most isn't all. IMO there's way too much code duplication in current init scripts. Most daemons are pretty standard and shouldn't need any special code in their init script. -- Olaf -- 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/aanlktimza__j14yxhh-7hq7kbkqg-vkvowceva2ef...@mail.gmail.com
Re: Upstart and sysvinit in packages - Policy needed
On Mon, 14 Feb 2011, Tollef Fog Heen wrote: That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I Yes. So, we also have to set where we want the low bar. don't believe there's a 1:1 correspondence between the semantics of all the different init systems, making this a very hard if not impossible job. Basically, anything that is not capable of doing _at least_ all that sysv-rc can do is still missing required features. We must first get to the point where the sysv-rc/startpar combination IS the most limited initsystem (removing or fixing anything that is actually more limited than sysv-rc+startpar). After that, we will be better able to see the way forward. -- 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/20110214161412.gb7...@khazad-dum.debian.net
Re: Upstart and sysvinit in packages - Policy needed
a way like metainit? http://wiki.debian.org/MetaInit The project died some two or three years ago and anyone is welcome to try to revive it. Mh it claims it would work only for simple scripts, not for any kind of scripts, so not all the packages could be converted. Bye -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Re: Upstart and sysvinit in packages - Policy needed
On Feb 14, Tollef Fog Heen tfh...@err.no wrote: That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I don't believe there's a 1:1 correspondence between the semantics of all the different init systems, making this a very hard if not impossible job. Agreed. If there is no or little improvement over sysv-rc then we can as well save the time needed for such a big change. I am even unsure that it's worth supporting more than one init package. -- ciao, Marco signature.asc Description: Digital signature
Re: Upstart and sysvinit in packages - Policy needed
On Monday 14 February 2011 20:55:06 Tollef Fog Heen wrote: | I believe we need to come up with a way where most or all package | maintainers (perhaps those handling kernel events and early boot stuff | should be expected) only need to maintain one boot setup for their | package, and this boot setup should be used by all the different boot | systems. That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I don't believe there's a 1:1 correspondence between the semantics of all the different init systems, making this a very hard if not impossible job. I was about to replying exactly that, only not so well written :-) In addiction to that, generally speaking, I was asking two things, one was if a policy could emerge to sort the init issues, the other point is regarding debhelper, maybe should I file a bug for the problem of debhelper hiding the sysvinit script if an upstart job is available? I have some doubts because the two questions are related and it is not properly a bug, more a wanted design derived from an hint as it is now. -- ESC:wq -- 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/201102142059.53736.marco.amad...@gmail.com
Re: Upstart and sysvinit in packages - Policy needed
On Monday 14 February 2011 21:00:09 Olaf van der Spek wrote: On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Petter Reinholdtsen | I believe we need to come up with a way where most or all package | maintainers (perhaps those handling kernel events and early boot stuff | should be expected) only need to maintain one boot setup for their | package, and this boot setup should be used by all the different boot | systems. That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Also, I Most isn't all. IMO there's way too much code duplication in current init scripts. Most daemons are pretty standard and shouldn't need any special code in their init script. The problem is that they may, not that they should have different initscripts for different init system. The best of two worlds would be having a sane defaults for any initscript out there from a common source but that a package maintainer could choose to carefully write customized init script for the differents init systems. -- ESC:wq -- 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/201102142102.11806.marco.amad...@gmail.com
Re: Upstart and sysvinit in packages - Policy needed
]] Henrique de Moraes Holschuh | On Mon, 14 Feb 2011, Tollef Fog Heen wrote: | That would mean limiting each init system to the limitations of the most | limited init system, which would be a sad state of affairs. Also, I | | Yes. So, we also have to set where we want the low bar. I'd rather prefer a solution where we either choose a single more capable init system going forward or we say that any init script system must support sysvinit scripts as well as having native jobs (be upstart or systemd) being able to mask sysvinit jobs of the same name. This would allow for improvements without being kept back to the extent we are today. | don't believe there's a 1:1 correspondence between the semantics of all | the different init systems, making this a very hard if not impossible | job. | | Basically, anything that is not capable of doing _at least_ all that sysv-rc | can do is still missing required features. Agreed. Do we know which, if any, are at that level? | We must first get to the point where the sysv-rc/startpar combination IS the | most limited initsystem (removing or fixing anything that is actually more | limited than sysv-rc+startpar). Must we? I'd like to get rid of the solutions that no longer fit, but at the same time, having to first remove whatever solutions exist today seems unnecessary for deciding on the road forward. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87y65icmav@qurzaw.varnish-software.com
Re: Upstart and sysvinit in packages - Policy needed
Hi, Am Montag, den 14.02.2011, 15:38 +0100 schrieb Tollef Fog Heen: ]] Petter Reinholdtsen | I believe we need to come up with a way where most or all package | maintainers (perhaps those handling kernel events and early boot stuff | should be expected) only need to maintain one boot setup for their | package, and this boot setup should be used by all the different boot | systems. That would mean limiting each init system to the limitations of the most limited init system, which would be a sad state of affairs. Not so sad, considering that a large portion of init scripts do hardly need anything more and become more robust if they are not scripts any more, but declarative descriptions. For the rest (early boot stuff, display manager, complex daemons), we’ll just continue writing having hand-written boot scripts. (I really think that much more in Debian should be declarative and thus consistent and robust, instead of repeatedly hand-written. What Michael Vogt say about maintainer scripts equally applies to init scripts: Another important problem to tackle is to make maintainer scripts more declarative. I triaged a lot of upgrade bug reports (mostly in ubuntu though) and a lot of them are caused by maintainer script failures. Worse is that depending on the error its really hard for the user to solve the problem. There is also a lot of code duplication. Having a central place that contains well tested code to do these jobs would be more robust. Triggers help us a lot here already, but I think there is still more room for improvement. (http://raphaelhertzog.com/2011/01/21/people-behind-debian-michael-vogt-synaptic-apt-developer/) But then, I should rather be quiet. I tried following this road and did not manage to push it enough (though not because it wasn’t possible, rather due to lack of time and motivation). Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
