On Sun, Mar 06, 2011 at 09:51:06PM +0000, Matt Willsher wrote:
I guess I should finish my mails before sending them. Sorry about that.
No problem. Gave me some time to do other stuff earlier tonight :-)
From what I've seen of debconf that hooks it provides tend to be limited 'get you up and running' sort of configurations.
Yes - lazyness is a virtue: For config options without big need for flexibility it is simpler to not offer install-time flexibility.
Let say, for instance, I'm a particular security requirement for my blend that dictate only certain ssh ciphers are allowed. The ssh debconf doesn't provide an interface for that. That leaves only the option of hacking at the file outside of debconf and the openssh-server packages control, which I gather isn't ideal in the Pure Blend model. I could submit a patch to the openssh-server package maintainer. But then so could others for other options particular to their requirements. Before you know, the package is handling every SSH configuration option. Is this the aim? If not, what is controlling those option?
Each package maintainer has the final say, as they have the ongoing task of _maintaining_ whatever the packaging consist of.
If I was the openssh-server package maintainer, and I received 8 different requests for improved install-time flexibility in config handling, then I would try to figure out how generally relevant each of the requests could be, how much it would complicate my ongoing maintainance, and if perhaps some of the requests could be merged together.
What if the user wants to tweak an option? Is that via the debconf interface too?
Could be. Most if not all instances f you experiencing a popup question during install of a package have been you interacting via debconf.
But no, it is not a goal for Debian Pure Blends that all config options that any user in the world might want to tune be manageable via debconf. Only options so common to tune that it is sensible to form a Debian Pure Blend around it is relevant here (although for other reasons it might still make sense to provide debconf interface for yet other options - like prompting for a password which is seldom relevant for a Debian Pure Blend to preseed the answer for).
The docs for the Pure Blend under http://wiki.debian.org/DebianPureBlends#Preconfigurethepackagesweinstall mention the use of cfengine. How and why does that fit in?
Once upon a time, before this concept was called "Debian Pure Blends", more ways of manipulating was considered ok than today.
Still today some feel that "Debian Pure Blends" need not be all "Pure", but I feel strongly about that:
To me an important issue is the implicit (and explicit too?) distro promise to users: Follow our usage rules, and we will stay with you in dealing nicely with your bugreports and offering you reliable upgrade paths.
Even when a "blender" like "Debian Freedom* Team" and/or a "deployer" like "PlugBoxing Company Inc." is involved before the installed Debian system reaches the hands of the final end-user, the end-user still assume a contract with Debian the distro. If a later upgrade to next cool shiny Debian explodes in her face, she loose faith in Debian, not the intermediary VARs (Value Added Redistributor/Reseller) that might be long gone by the time of said upgrade. And when Debian slowly realize a pattern of end-users of a certain "blend" loosing faith, its developers will loose interest in cooporating with those VARs - or possibly with *any* VARs. And all would loose.
To me, "Debian Pure Blend" is a branding meant to ensure both Debian and end-users can still rely on the contract. It is a way for VARs to say "all things served as if served by Debian itself".
...I even go so far as ensisting that only things actually served by Debian itself is really truly a "Debian Pure Blend". The reason for this is that there are tricks that can be played at install-time to circumvent Debian Policy and thus create installations that Debian package maintainers cannot recreate and therefore also not support (Debian Edu currently use such trick on their install media).
Why not use that for most cases and provide consistency? It could even call the debconf bits if need be. Common promises and functions could be distributed as part of the packages. It's like debconf on steroids isn't it?
CFengine, Puppet, etc. are tools that are "hacking on top" of an installed Debian system. They are automated extensions for the _sysadmin_ of a system.
"Debian Pure Blends" is extensions to the _package maintainer_ role which is different. Not easily discovered in normal use, often only in special situations like dist-upgrades.
If debconf isn't the 'One True Way(tm)' what other ways are their that maintain a seamless experience for the user?
* Adjusting default config to cover more use cases. * supporting config.d style snippets * provide tools like the apache2 "a2enmod" script (no doubt more that I can't recall right now or don't know about yet)
How does the additional configuration ( I want a pretty wallpaper for my security distro on GNOME) fit into a Pure Blend? Would it be expected that there be a metapackage with the wallpaper in, perhaps with the other dependencies and suggestions?
not sure I understand what is your question here. Yes, it might make sense for some security-oriented "Debian Pure Blend" to also change wallpaper of the GNOME desktop. And yes, it is sensible to provide such wallpaper in a package specific for that blend.
Some blends need more complex configuration which is not yet possible in Debian. An example is Debian Edu - see http://bugs.debian.org/370342 for an example of their (very few remaining!) needs.That looks like it isn't because it's pending an architectural change, just that no patch has been produced for the package to provide the debconf hooks?
Yes, that might be the case for this particular bug. Apparently it is not simple, however, since that bug has been open for more than 4 years and I know that Debian Edu is quite interested in becoming a "Debian Pure Blend" which that bug is a blocker for. You can try read the underlying http://bugs.debian.org/311188 for more insight, but do not expect me to be able to clarify: I failed explaining its importance even to the Debian release managers for several releases.
The configuration requirements for packages could be quite onerous on the packager. Do packagers generally accept the improvements and requests submitted to them? Do they sign up to the idea of a Debian Pure Blend? Do they even reject patches?
When the packagers agree that it is improvements, then yes they generally accept them.
Many (loudly voiced) Debian developers find "Debian Pure Blends" a lousy term - but then again it seems to me they misunderstand the main point of being something "all inside Debian itself" and then obviously find the combination of "Pure" and "Blend" weird.
I believe Debian developers/packagers are generally happy about their packages being easily consumable by derivative distributions - and therefore also by "derivatives-not-deriving-at-all" i.e. Pure Blends.
But really packagers need not like or care about the "Debian Pure Blends" concept. It is a matter for those interested in systematic customizations with least long-term maintainance - i.e. a matter for teams targeting a certain group of end-users.
Sure packagers reject patches. But (assumably) for technical reasons - not because they come from some team they do not like the concept of. Similarly when filing a bugreport you shouldn't argue that the reason is that you are part of a team which you find is highly respected and cool to serve - you should point out the benefits for the _users_ of that particular package (users for whom you believe being a representative of a fair amount of).
How would complex configurations be handles? (e.g. BIND configuration and zone files) ?Depends on each package involved - both technically on its configfile formats (e.g. ability to consume config.d folders) and practically on the interest of the package maintainer(s) in taking the responsibility to _maintain_ the wanted configuration flexibility.But if I'm managing my zone and I web to add a record through my fancy web UI, who touches the config files? the BIND package debconf hooks, the web app, something else? What about those files at already exist, like the options file? Should the web app be changing that? If it did, doesn't that cause upgrade problems with config merges?
If you "web to add" data then you are a sysadmin doing things _after_ final install of the system.
"Debian Pure Blends" is all about doing customizations which unfold _during_ install - not after.
How can duplication of data be avoided?I don't understand - could you give an example?Take the SSH example above. Not only do we have a ban on some ciphers in SSH we want them banned across all packages on the system. mod_ssl isn't to use them, neither should any other TLS/SSL using software. If each package is managing it's own config there isn't a central configuration with out providing additional scaffolding. And then it's dependant on the package being able to apply it's configuration.
Even if packages are managed by separate maintainers, there is nothing stopping multiple package maintainers to coordinate their technically separate works. Debconf supports this with special system-wide options.
Someone needs to coordinate such additional efforts. Could very well be the ones most interested in such unification - i.e. someone involved in developing a "Debian Pure Blend".
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature