On Sat, 08 Jul 2000, Ethan Benson wrote: > On Sat, Jul 08, 2000 at 11:05:12PM -0300, Henrique M Holschuh wrote: > > Unfortunately, the *current* LSB standards has that status thingie in it. > > Debian will eventually adopt the LSB, so we'll either have to implement (and > > LSB also wants to use RPM i guess we better plan on throwing out dpkg > and apt-get eh? Are you kidding? The LSB can ask for a package system, but if they ask for RPM they've lost us (just try forcing RPM on debs, and you'll at most manage a project split IMHO, not to mention an year long flamewar), and THAT would be blatantly stupid and go agaist their (public, oficial) charter. > frankly from what i have seen of the LSB they are including FAR too > much redhat non-standardisms. if they want to create a fucked up > standard then LSB be damned i hope debian ignores it. It'd be much more useful if you would help to get the crap out of LSB (and please be prepared to assume a common middle ground), so that we end up with a well-done LSB. > if LSB wants us to use that stupid redhat esque /etc/rc.d/init.d > instead of /etc/init.d will we do that? i hope not. if LSB wants us to > throw away dpkg in favor of that peice of manure RPM will we do that? No, never. But the LSB does not want (so far) that rc.d crap, and Debian has a voice there. Make it heard, instead of complaining here. A proplerly-done and widely deployed LSB is USEFUL, so lets work for that goal please. > > BTW, a working (as in well behaved, well implemented, AND accurate) status > > function is useful for sysvinit wrappers. Debian will have one of these > > (optional, the flamewars will make sure of THAT at least) sooner or later, > > and IMHO they're the reason the LSB left the status stuff in there. > > i think a accurate and useful status function is impossible, and a > waste of time. besides that what about the people use use filerc It cannot be impossible. If it is impossible, that means killing the daemon is not accurate either, and that is a critical bug by debian standards. Yes, this means we'll have to actually dirty our hands and patch daemon code so that it can be accurately identified (for both the status AND the stop function), but so what? THIS isn't bload, this is better quality. Maybe status) is bloat, but it is small bloat (if the daemons are coded in an appropriate fashion for a daemon, that is) and it is useful for an entire class of utilities. > instead of sysvinit scripts? some people hate sysv. the burdon The LSB currently defines the standard for sysv scripts, so if we're to follow the LSB, our sysv scripts should conform to it (note that I didn't say conform to *current* LSB. If it is broken, help fix it). Our non-sysv init systems are UNDEFINED as far as the LSB is concerned. For non-sysv systems, we need an abstraction layer. That's the way we'd do it in Debian (actually, AFAIK that is the way we're trying to do it in Debian, integrating sysv-init and non-sysv-init schemes are a major TODO right now). Get this layer into LSB (it's already there, I think) and Debian policy, it's needed and it's needed now. Normal programs only need a very well-defined interface to the init system: they need to add and remove themselves. A beefed-up update-rc.d if you will. This is not bloat, we need it for non-sysv-init integration. The package system needs also to be able to start, stop and force reload of the init-scripted stuff for upgrades. Again, a beefed-up update-rc.d, and quite easy-to-implement wrapper at that. This is not bloat either, we need it for non-sysv-init integration. If the non-sysv-init system does not accept sysv init scripts as input, the user will have to read the app's init script and reimplement it anyway, so that's not an issue. Apps which need intimate control of the init system will only work with sysv. So what? There is no acceptable way around that, other than porting the app to your new init system anyway, so that's not an issue either. > should be on the eye candy wrapper people to make thier wrapper work, > not the initscript maintainers. See above. > > Yes, you can. Automated tools, however, could probably benefit greatly of an > > accurate (and consistant) status function (which is supposedly tailored to > > detect if a certain daemon is either running or dead in the most accurate > > way it can be done for that particular daemon)... > > bloat. IMNSHO this will be the decline of GNU/Linux, where Cool down, will you. As someone else said, this 'bloat' is useful for clustering. THIS is a good feature, and it doesn't require much effort other than doing things right to begin with in the daemon side. It won't add more than a few kB of (hopefully clear) script code to your system. > i think this LSB should define very little, individual distributions > should be able to write their initscripts however they damnwell > please, the individual daemon should not even include such things. The LSB must define the abstraction layer for registering, removing, starting, stopping and force-reload of daemons (and one that works with non-sysv-init systems at that). The LSB is also trying to define a common ground for sysv-like init systems so that clustering and eye-candy tools can be easier developed. It is possible to do this in a non-braindamaged way (but the *current* LSB way is not a very good one, although it's not braindamaged ;-) ). It's also trying to define a common ground for sysv-like init SCRIPTS so that the package system abstraction layer can retrieve some data from third-party sysv-like scripts. As long as not including that information when it's pointless is acceptable, this is not bloat either. > > PS: I am against anything more damaging to the holy KISS principle than a > > conffile defaults (variable assignment ONLY) directory (with conffile init > > agreed, but i really don't think its worth it. I will only accept that a defaults hierarchy is useful if: 1. Heavy changes to a init script in an upgrade won't get screwed by it. Stuff such as needing a completely different set (and empty IS a possible set :-) ) of configuration variables in the defaults hierarchy. 2. The defaults hieararchy will NOT suffer constant changes. If a package has to update the crap in there almost every other version, it's better off by using only a init script. > > scripts). RedHat-style init scripts be damned, the stuff the LSB asks us to > > do (right now) is already complicated enough to do _right_ (half-assed > > solutions need NOT apply). > > screw the LSB then, i don't want debian to be ruined just to comply > with some dubious `standard' Man, we're writing the LSB right now. The correct approach is to make sure it doesn't suck. Look, I'm willing to take a few hours during the next two weeks to study the LSB, talk to the Debian maintainers of both SYSV and non-SYSV init systems, write up a policy proposal for *DEBIAN* that implements all this crap in a sane way AND write all the abstraction layer scripts to go with said proposal, so that it is "show the code" ready. Senseless bloat? No way, this will enable non-sysv init systems in Debian, so it's useful. I'll do that AS LONG AS you will help me with it. You want only the minimum amount of "bloat" to creep in? Good, help me with it or don't complain. I hope you realise that we'll probably have to include the status thingie for the clustering guys, but at least YOU can help do it in the less bloatful and most accurate way possible. Please realise that I intend to conform to the LSB-defined return status-codes for sysv init scripts were possible, unless you _prove_ me they're braindamaged (in which case a written request for a fix to the LSB *will* be sent). You'll notice this is independant on the defaults stuff, that can be added (or not) later to the policy. Do we have a deal? Once this goes through all the policy discussion and is implemented (it will have to be, in one form or another. The non-sysv guys need it), we'll have something to show the LSB guys how it should be done. -- "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
Attachment:
pgpxQu61GBQAW.pgp
Description: PGP signature