On Fri, Sep 30, 2011 at 12:35 PM, Adam Nielsen <a.niel...@shikadi.net> wrote: >>> It is a limitation I think of any/every configuration control system. >> >> Why can't it show the diff / update like dpkg does? > > It could, but because it's designed to control large numbers of machines it > would need some careful planning to avoid showing the same/similar diff > dozens of times. It's also distribution neutral, so it would have to be > able to parse output from many versions of dpkg (not just the latest), as > well as 'emerge' on Gentoo and countless others. Since Puppet runs as a > daemon (syncing changes every 15 minutes or so) there would need to be some > way of notifying a user, e.g. via e-mail and having them respond. It would > certainly be doable, but it's a huge job, so I don't think it's a surprise > nobody has done it yet.
So how does it handle updated conf files? >>> Not quite. Since enabling IPv6 support works the same on any distro, it >>> shouldn't go in the platform-specific section. I would say, as a rough >> >> Does it? The IPv6 code is Debian specific (AFAIK). > > The code is Debian specific but the resulting lighttpd options aren't. If > you're using Puppet to configure lighttpd you are unlikely to want to > autoconfigure IPv6, Why? Are IPv6 and Puppets no friends? > so you would hard-code the IPv6 stuff in the config file > if you wanted it on, and not use the Debian script. If you did want to > autoconfigure it you'd include your own script (or copy the Debian one...) > so it worked on any distro. > The benefit is simply that you don't have to maintain those options in your > configuration repository, keeping it as distribution-neutral as possible. Right >> Security (and stable) updates are unlikely to contain updated conf files. >> >> BTW, I've requested upstream to enable IPv6 by default or to provide a >> better/easier way to enable it. Unfortunately they didn't want to do >> this for 1.4. > > I think the way you have done it is fine for anyone editing the > configuration by hand, it just unfortunately doesn't make it as clean when > using an automated tool. I think this was the original reason behind the > general move to conf.d style directories - so automated tools could add and > remove configuration options without having to modify individual files. Split configs also avoid conflicts when automated tools aren't used. Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org