carl wrote:Thanks for the pointers. We agree that this situation isn't good, and for BubbaTwo we have begun process of moving config-file only changes into bubba-backend package using dpkg-divert instead (cups and samba have been updates as of yet in claire). If this goes well, we might do the same for BubbaServer::lenny. Regarding udev, that's a bugger. The reason for the really OLD udev is because we retain the older 2.6.16 kernel, and never versions of udev requires at least an 2.6.18 kernel. Sadly upgrading the kernel in BubbaServer includes the risk of bricking.
Hey, we live in a world of perpetual beta's where noone expects that "the final" solution exists. So, I wouldn't go as far as describe the situation as not good. I like my Bubba Sever and I think you've done a great job. It's just that it's always possible to find something that can be done better, or that the definition of what's "good" changes over time.
I like the simplicity of Bubba Server and the fact that it builds on Debian. The only thing I miss is an active community that could maintain an independent image for Bubba Server. Of course, I can only blame myself; it's a user responsibility to drive such a community, but so far, I haven't had the time to get involved in it. Nonetheless, that's actually part of the motivation behind my posts; the more the Bubba software resembles a Debian release, the easier it will be for an independent community to take over maintenance of Bubba Server.
I actually didn't know about dpkg-divert until you posted your comment. Nice tool. However, reading the description of the tool makes me question whether it's the right tool for the job. As far as I can tell, applying dpkg-divert on a configuration file will imply that future upgrades from Debian will never touch the Bubba specific configuration files. I would tend to think that, in some cases, this may actually be unfortunate, as it could leave a system non-operational after an upgrade or miss out security fixes that were implemented in part as configuration changes.
Compare this with a scenario where the Bubba specific configuration changes are applied directly to the Debian default configurations from, say, backend.pl or similar script that is executed once after a fresh installation. The Debian policies state that user modifications of configuration files must be left untouched by upgrades, so Bubba specific configuration changes applied this way would survive upgrades while allowing for Debian configuration file updates to take effect as well. That sounds more like what I would prefer. Or perhaps I misunderstood what dpkg-divert can be used for? Also, to be honest, I must admit that I vaguely remember a few cases, where a Debian package upgrade was far from providing a smooth upgrade when the package system tried to preserve my configuration changes.