On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote: > Once upon a time, Matthew Garrett <mjg59@xxxxxxxxxxxxx> said: > > The suggestion isn't that having the options is wrong > > Well, that's what you said before (conveniently snipped from your > reply). You compared CLI args/env vars to the BKL as something to be > eliminated; specifically, you said (and I quoted): > > > In this case there are sound > > technical arguments against configuration by command line argument or > > environment variable > > You have still failed to enumerate even one of the "sound technical > arguments". "Configuration by", not overriding configuration. It's a mistake to have your daemon's configuration be handled by a shell script that's sourced into existing environment. It's reasonable for an admin to override configuration on an as-needed basis. > > it's that having > > them as the primary means of configuration is poor design. If your > > entire configuration takes the form of a shell script that constructs a > > set of command line options then you've increased fragility for no > > benefit. Having a proper configuration file and allowing admins to > > override specific aspects of that from the command line isn't a problem. > > You are moving the target (to a worst-case example) and still not > winning your argument. The discussion was about having significant quantities of configuration in /etc/sysconf in the form of shell fragments. > This is more than theoretical to me; a small package I maintain is one > example of a command-line configured daemon. The shmpps daemon is a > tiny little daemon that reads a timing pulse-per-second and updates a > shared memory segment. It uses a few command line arguments to set the > source port/type and shared memory segment destination; right now, that > is done for the init script by a file in /etc/sysconfig. And that's a bad thing to do. You're sourcing your configuration in an unsanitised environment. There's a huge number of ways that this can go wrong depending on the admin's local configuration, which is clearly undesirable. > This is a small, light-weight daemon, and doesn't need a configuration > file parser. This is a valid way that Unix daemons have run for > decades, and you are saying that should be removed. I guess every small > daemon now needs to include its own config file parser, replacing the > already-existing getopt() call? How is this "better"? Nobody's said it should be removed. Lennart's said that it sucks, and I agree. But all of this would still be better with a simple config parser that's shared between any daemons that want it. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
