On Wed, 2010-07-21 at 08:03 -0800, Jeff Spaleta wrote: > 2010/7/21 "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx>: > > Admins will need to know that they have to use chkconfig for services that > > do not have a native systemd $service file. ( legacy for services ) > > > > And as the general rule goes "native configuration breaks legacy > > configuration" so if a native systemd $service file does exist than changing > > service via chkconfig no longer will work. > > > Would it be reasonable to extend chkconfig so that it can know which > services it can no longer control and provide a pointer blurb to > admins when they try to use chkconfig with those services in the F14 > timeframe. The reality is any change to scriptable behaviour is a > pitchfork wielding mob scenario. (mental note: this would make a good > Simpson's episode) > > > If we are breaking curmudgeony workflows it be really nice to provide > some breadcrumbs along the way to help us old dogs learn new tricks. > Admins are going to need to learn how to use and configure systemd > native configs in the F14 timeframe, feedback from the "legacy" system > tools when we need to recondition our muscle memory and are scripted > actions would go a long way to lowering the frustration level...if the > native/legacy tool break can't be avoided. It occurs to me that chkconfig isn't, in packaging terms, part of either upstart or systemd. It's just a standalone utility, it builds from its own SRPM. systemd being an open source project, its interfaces shouldn't be hard to figure out, and hey, I seem to recall seeing quite a bit of documentation, and Lennart seems perfectly happy to provide info when asked. So...why can't any of those complaining about this just go ahead and patch chkconfig to support systemd? It's not like Lennart can stop you, no matter how much he twirls his moustache ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel