Spec URL: http://stevemilner.org/tmp/upstart.spec http://stevemilner.org/tmp/event-compat-sysv.spec SRPM URL: http://stevemilner.org/tmp/upstart-0.3.9-1.fc8.src.rpm http://stevemilner.org/tmp/event-compat-sysv-0.3.9-1.fc8.src.rpm Description: Upstart is an event driven init system and service manager. It will allow us to move from preset runlevels starting a certain set of services to on-demand service activation for all services and unified monitoring and managing of both system and session level services. Listed above are two packages. At the moment these two are essentially inseparable. The upstart package provides the new init system, and the event-compat-sysv package provides compatibility with the current SysV init scripts.
You have to submit event-compat-sysv as a separate review and mark it as a dependency of this review so that they can be reviewed independently.
(In reply to comment #1) > You have to submit event-compat-sysv as a separate review and mark it as a > dependency of this review so that they can be reviewed independently. I have now done this.
package set conflicts with sysvinit. maybe this can be worked around by using the one of the suffix configure flags and adjustments in the actual job files. also id recommend to use %find_lang %{name} at the end of the %install section and %files -f %{name}.lang instead of packaging the translation files manually (you can remove them from the %files section then).
This package will conflict with sysvinit, it will not be possible to install both. I'd been waiting to determine whether a Conflicts or Obsoletes entry was more appropriate. Also since our init-scripts package still requires several tools from the sysvinit package, those will either have to be split off of the sysvinit package or repackaged here (I like the former solution better, and am still trying to work with Bill Nottingham on it). Will fix the language issue tonight and re-post.
It will be much better for testers and reviewers to be able to install both packages in parallel. initng can be installed in parallel, for example. I am completly new to upstart, but it is a bit strange that /sbin/init is in this package. Can't upstart be used by only tweaking inittab and using the previous /sbin/init?
More on the packaging, unless I am missing something, it looks like nih should be separated upstream, having that library bundled with upstart seems wrong. In fact libnih seems to be a separate project but I haven't found any release. If the .la aren't specifically useful they shouldn't be shipped. Static libraries should go in -static subpackages, or not be shipped at all. .so files should be in the devel packages. You have to use %find_lang for the locales packaging (it is covered in the guidelines), as also said in an above comment. Also I suggest looking at the rpmlint output.
(In reply to comment #5) > It will be much better for testers and reviewers to be able to > install both packages in parallel. initng can be installed in > parallel, for example. > Initng is packaged as something for more advanced users to experiment with. Its packaging style is not well suited to being the default out of the box init system (which this package hopes to be, FESCo will be talking that over on Thursday). > I am completly new to upstart, but it is a bit strange that > /sbin/init is in this package. Can't upstart be used by only tweaking > inittab and using the previous /sbin/init? In a word: No. Upstart's init is a full event-driven service manager that not only starts services but can monitor them, restart them, and notify the system of their state. (In reply to comment #6) > More on the packaging, unless I am missing something, it looks > like nih should be separated upstream, having that library > bundled with upstart seems wrong. In fact libnih seems > to be a separate project but I haven't found any release. > > If the .la aren't specifically useful they shouldn't be shipped. > > Static libraries should go in -static subpackages, or not be > shipped at all. > > .so files should be in the devel packages. > After further talks with upstream it turns out that neither of the lib packages need be shipped with upstart. I will probably strike them from the package for now. > You have to use %find_lang for the locales packaging (it is covered > in the guidelines), as also said in an above comment. > Working on that.... > Also I suggest looking at the rpmlint output.
One issue is that in parallel with this, unless something has changed with upstart, we need to figure out how to get SELinux policy loaded. The simple way is in initramfs (just a simple matter of code), but it needs done.
(In reply to comment #8) > One issue is that in parallel with this, unless something has changed with > upstart, we need to figure out how to get SELinux policy loaded. The simple way > is in initramfs (just a simple matter of code), but it needs done. I'll poke upstream about this. It should be easy to plug something in. Upstart has proven highly flexible so far (for example, early login is now a one-liner change).
Doing it in initramfs means upstart doesn't even need to worry about it; if upstart's init itself did it, it would need to reexec itself under the policy (ick).
ahh. probably best to do it the other way then :)
well actually: it is technically possible to package it in the proper way to make it parallel installable. at the very least by using the alternatives system. if it is packaged this way (and sysv too) it would be rather easy to also actually package initng with using alternatives and properly switch between those in an easy and somewhat clean manner. actually id see a parallel packaged approach better for something that crucial as an init system until a tester can be sure it does the job properly and doesent resolve in an unbootable system because of any potential reason. field testing will show that actually. just my personal opinion.
Well, except I doubt we'd ever ship the system init daemon in a final release as something alternatives-able. So, it's a lot of initial work for little long-term gain.
(In reply to comment #7) > (In reply to comment #5) > > It will be much better for testers and reviewers to be able to > > install both packages in parallel. initng can be installed in > > parallel, for example. > > > > Initng is packaged as something for more advanced users to experiment with. Its > packaging style is not well suited to being the default out of the box init > system This seems to be untrue to me. Having initng as the default out the box init system only requires changing grub command line. Anyway it isn't the subject of this submission. Using alternatives seems right to me since it would allow to keep the old init system around after upstart has become the default system. (In reply to comment #13) > Well, except I doubt we'd ever ship the system init daemon in a final release as > something alternatives-able. So, it's a lot of initial work for little long-term > gain. Why not? This would allow users to chose the old init system if they happen to need it?
If we need more than one init system, we've failed. (See also: "not about choice", (c) 2008 ajax.)
(In reply to comment #15) > If we need more than one init system, we've failed. Fedora as such shouldn't need it but we cannot discard the possibility that somebody steps up to keep on maintaining the old system. In that case the alternative would still be useful. It could also be used by initng, by the way, or the next init system, with early planning and testing. > (See also: "not about choice", (c) 2008 ajax.) I disagreed in the thread, I won't agree now...
(In reply to comment #16) > (In reply to comment #15) > > If we need more than one init system, we've failed. > > Fedora as such shouldn't need it but we cannot discard the > possibility that somebody steps up to keep on maintaining the > old system. In that case the alternative would still be useful. > It could also be used by initng, by the way, or the next init > system, with early planning and testing. > This defeats the whole purpose of the package. While this release is intended to simply swap in upstart in an unobtrusive manner, taking full advantage of Upstart's power is going to involve many changes to our current system. While packages wishing to install LSB/SysV scripts will still work, there will eventually come a day when none of our scripts use these mechanisms (i.e. when a default fedora install has an empty /etc/init.d). This package provides compatibility with sysvinit, but an alternative it is not. Upstart is going to allow us to build a very powerful and robust init system, but it will be one which init-ng and sysv will likely not be capable of driving. By all means judge this package with the weight it demands. This is a very real and very permanent change to a very central part of Fedora. However, all of this gets off topic. The purpose of this bugzilla is to review the practice of packaging upstart, not the principle. That we can save for Thursday. > > (See also: "not about choice", (c) 2008 ajax.) > > I disagreed in the thread, I won't agree now...
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > If we need more than one init system, we've failed. is the same true for mailservers? :=) > > > > Fedora as such shouldn't need it but we cannot discard the > > possibility that somebody steps up to keep on maintaining the > > old system. In that case the alternative would still be useful. > > It could also be used by initng, by the way, or the next init > > system, with early planning and testing. > > > > This defeats the whole purpose of the package. no it doesent because technically the issue is similar to postfix and sendmail. postfix was also designed as a drop in replacement and properly packaged it still doesent conflict. > > While this release is intended to simply swap in upstart in an unobtrusive > manner, taking full advantage of Upstart's power is going to involve many > changes to our current system. While packages wishing to install LSB/SysV > scripts will still work, there will eventually come a day when none of our > scripts use these mechanisms (i.e. when a default fedora install has an empty > /etc/init.d). This package provides compatibility with sysvinit, but an > alternative it is not. Upstart is going to allow us to build a very powerful and > robust init system, but it will be one which init-ng and sysv will likely not be > capable of driving. vice versa upstart cant use initng scripts so i am not sure if this is a real technical argument. > > By all means judge this package with the weight it demands. This is a very real > and very permanent change to a very central part of Fedora. I was trying to do that above because replaceing a mailserver couldnt make a system potentially break it to an extent that it doesent boot anymore. > > However, all of this gets off topic. The purpose of this bugzilla is to review > the practice of packaging upstart, not the principle. That we can save for Thursday. Agreed. Personally i consider a package that conflicts as a broken package by default unless it really Obsoletes: the older version for good ;). I am not sure if completly obsoleting is the way to go. > > > > (See also: "not about choice", (c) 2008 ajax.) > > > > I disagreed in the thread, I won't agree now... > >
(In reply to comment #16) > (In reply to comment #15) > > If we need more than one init system, we've failed. > > Fedora as such shouldn't need it but we cannot discard the > possibility that somebody steps up to keep on maintaining the > old system. In that case the alternative would still be useful. > It could also be used by initng, by the way, or the next init > system, with early planning and testing. > Um. Seeing as compatibility with SysInitV will get worse over time (as services' init scripts get modified to integrate more tightly with Upstart), I'd say at some point going back will not be possible anyway.
New spec file here: http://www4.ncsu.edu/~cjdahlin/upstart.spec New srpm here: http://www4.ncsu.edu/~cjdahlin/upstart-0.3.9-2.fc8.src.rpm
MUST: - Package meets naming guidelines - OK - Spec file matches base package name. - OK - Spec has consistant macro usage. - *** - Meets Packaging Guidelines. - OK - License - GPLv2+ - OK - License field in spec matches - OK - License file included in package - *** - Spec in American English - OK - Spec is legible. - OK - Sources match upstream md5sum: 794208083d405ece123ad59a02f3e233 - OK - Package needs ExcludeArch - N/A - BuildRequires correct - OK - Spec handles locales/find_lang - OK - Package has %defattr and permissions on files is good. - OK - Package has a correct %clean section. - OK - Package has correct buildroot - OK - Package is code or permissible content. - OK - Doc subpackage needed/used. - N/A - Packages %doc files don't affect runtime. - OK, once they're added - Headers/static libs in -devel subpackage. - N/A, nuked - Spec has needed ldconfig in post and postun - OK - .pc files in -devel subpackage/requires pkgconfig - N/A - .la files are removed. - OK - Package compiles and builds on at least one arch. - once issue #1 addressed, yes (tested x86_64) - Package has no duplicate files in %files. - OK - Package doesn't own any directories other packages own. - OK - Package owns all the directories it creates. - OK - No rpmlint output. upstart.x86_64: W: conffile-without-noreplace-flag /etc/event.d/logd This may be OK, if this isn't meant to be user modified. - final provides and requires are sane: *** SHOULD Items: - Should build in mock. - OK (tested x86_64) - Should build on all supported archs - didn't test ppc - Should function as described. - *** - Should have sane scriptlets. - N/A - Should have dist tag - OK - Should package latest version - OK Issues: 1) %configure --enable-compat=sysv --sbindir=/sbin --libdir=/lib Needs to be --libdir=/%{_lib}, otherwise build will fail on x86_64, ppc64. 2) No docs, including licenses Probably should include ChangeLog, AUTHORS, COPYING, NEWS, README, TODO, HACKING 3) Should this package require event-compat-sysv? Should it obsolete/provide sysvinit? 4) Re: functionality. I think that will go in a separate bug.
5) The runlevel man page ends up screwed up somehow.
1) Will fix soon. 2) Ditto. 3) event-compat-sysv provides sysvinit. It requires upstart. 4) Broken in part due to the lack of a sysvinit-utils package. Still working that out. 5) I'll look into this.
The problem with #3 is that something still needs to obsolete sysvinit to a) force the upgrade b) get sysvinit off the system.
That would be event-compat-sysv :) It seems strange, but in effect, it is that collection of event files which enables sysv compatibility, not upstart.
New package: http://www4.ncsu.edu/~cjdahlin/upstart-0.3.9-3.fc8.src.rpm http://www4.ncsu.edu/~cjdahlin/upstart.spec
For #4, there is a patch in bug 431110 for sysvinit, if you want it for testing. I suppose at some point those should move to util-linux or similar, but that's beyond the scope of this. See also the 'upstart' meta-bug tracker. Changes added address issues #1, #2, above. #5 is a run-of-the-mill bug, not relevant to packaging. Do you need a sponsor?
Created attachment 293754 [details] patch for gcc-4.3 This is needed to build with gcc-4.3 - a missing #include.
Yes, I do need a sponsor. Also, 5 Works For Me, so not sure what's going wrong.
Shouldn't every non-versioned .so library land in -devel? Ie. %{_libdir}/libupstart.so And, other, %find_lang should be probably used.
(In reply to comment #30) > Shouldn't every non-versioned .so library land in -devel? > > Ie. %{_libdir}/libupstart.so > > And, other, %find_lang should be probably used. Are you looking at the latest package? Your concerns seem out of date.
I'm not sure if this is approved or not. Whoever did the review should mark the flag appropriately. If you still need a sponsor after that (you shouldn't, as both notting and tibbs can sponsor you), I'd be willing to.
OK, approving and sponsoring; please enter CVS request. I'd like to co-maintain it for the moment, if you don't mind. For builds, please build into dist-f9-upstart until we get some of the bugs on the tracker worked out.
New Package CVS Request ======================= Package Name: upstart Short Description: An event-driven init system Owners: sadmac,notting Branches: InitialCC: Cvsextras Commits: yes
cvs done.