Manoj Srivastava wrote: > On Tue, Aug 25 2009, Michael Biebl wrote: > > >> first of all, thanks for the patches and interest you've shown so far. > >> As maintainer of upstart I currently prefer the initramfs solution given the >> following arguments: > >> - selinux is only used a by very low percentage of our users > > But it is enabled in vompiled in by default in mainstrean > Debian, and if upstart wants to get into Debian, perhaps it should > follow Debian conventions
upstart is already in Debian, fwiw. What we are talking about here, is how to add support for running /sbin/init under selinux. There is no such thing as a "Debian convention" that this has to be done by patching init. >> - linking against selinux means the list of dependencies increases, which >> increases the potential for failures. I try to keep the dependencies >> as minimal as possible. > > Adding a dependency on an initramfs is then a fail. None of my > non-laptop machines use an initramfs, and so upstart can't be used Upstart can very well be used without an initramfs. >> - the package will be entangled in libselinux testing transitions (libselinux >> seems to bump shlibs very regularly) > > I do not think you understand the difference between an SONAME > change (API changes) and a shlibs bump (ABI change). Your package will > noit have to be recompiled or re-uploaded because of a shlibs > change. No transition here. > > Indeed, thre has not been a libselinux transition since forever. Manoj, I really don't like this way you present your arguments here. See my PM about that. FWIW, I perfectly know what I'm talking about. >> - I don't see a good reason to patch each and every /sbin/init if we >> can just add support in one place, i.e. the initramfs > > Because initramfs is not unoversal, and should not be made a > requirement to run Debian. Well, what you ask me about, is to make libselinux a requirement and enforce that to upstart. See? What I try to explore is if there are better alternatives, and the initramfs solution looks like a simpler and easier to maintain solution to me. >> - I would include the selinux initramfs bits in one of the selinux >> packages, so people not using selinux won't get the additional >> bloat. Btw, it would be good to have hard numbers, by what size the >> initramfs increases. I don't use selinux, so I can't tell. > > > >> - upstream selinux and upstart maintainers seem to prefer the >> initramfs solution. Without compelling arguments I won't divert from >> that decision. > > Upstream SELinux people have said no such thing. Indeed, > upstream init has SELinux patches in mainline now. No, upstream init has no selinux support. You are wrong here. > >> - given that upstream is not going to include the selinux patch in >> upstart (as it currently stand), I'd have to carry the patch >> forever. Not something I'm very fond of. > > It is not a big patch, and has not had many issues in init > before it went mainstream. An upstart selinux patch has never went upstream. Cheers, Michael P.S: Manoj, I know your kind of argumentation style, so I'll just stop here, because I don't want to engage into endless, pointless discussions. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
