On Thu, Feb 27, 2003 at 05:40:17AM +1000, Anthony Towns wrote: > But aside from that, I think there's an interesting point here that > hasn't quite crystallised yet. It's related to the flavours stuff that > Bdale has mentioned a few times that sparked a fair bit of interest at > the Debian miniconf at linux.conf.au this year. > > At its simplest, I think, the idea is that we ought to be able to > "extract" a flavour from Debian [1] in some automated way, and that > we should then be able to give this flavour to someone who can then go > about their business without having to remake all the same decisions. > > There are obvious things that this would mean. A flavour would have to > be able to include various non-standard packages. It'd have to be able > to stop the user from being prompted for various things. It'd probably > have to be able to tell the installer exactly what to do. > > There are more subtle things too, that are harder to get right. It'd > have to allow you to choose other packages without presenting you with > the entirety of Debian, but still cope with dependencies and conflicts > correctly. If you've been given the Internet server flavour of Debian, > you may or may not want to install postfix or sendmail, but you don't > generally want to have to wade through hundreds of games or thousands > of lib* packages. This probably means you want to integrate with dselect > and aptitude, somehow. > > You also need to be able to configure packages automatically. And when > you upgrade, you definitely don't want to be confused with messages from > dpkg that claim your automatically configured conffiles were modified. > > You also need to make sure you can back out of a flavour if you find > you're no longer using a machine for the same purpose as you were in > the past. Or switch to a different flavour, or run multiple flavours > concurrently. > > The canonical example of flavours is a "Debian for HAMs" CD. Others > might be "Debian GNOME", "Debian Desktop", "Debian for Small Business", > "Debian Server", "University of Debian CS Dept Workstation". This is intriguing. I hadn't heard about the flavors idea before. Right away it seems like it would need a whole new layer on top of the current infrastructure acting as glue, somewhere between the package level and the stable/testing/unstable branch level. What you described seems to me to be more like a more expansive version of tasksel, which doesn't really solve the problem. What I see is a need for packages to be able to tell what flavor they are currently being used in context of, in order to make informed decisions for the user. Simply choosing some apps for them doesn't really make any choices. Aptitude and dselect would obviously use this sort of information to choose what to display to the administrator, but I think every substantial package would need this in some sort of substantial way. Take a person who installed a home server flavor. The apps installed by default for this flavor could differ from the standard server flavor, but further, the debconf questions asked at install time could be less or totally different in this case. It would be easy to simply set certain questions to a higher priority in the home server flavor, but the wording of the questions could be all together different, with more hand holding or leading questions for the home server version. The package would simply query what context (flavor) it is in, and adjust things accordingly. The problem then becomes how to manage the different flavors. Is there an authoritative central list, like the package subsections, that has to be changed by policy? Can developers simply do things haphazardly, starting a flavor when they feel like it? Another big issue with this that I see is the massive amount of work that the subprojects have to do. This would distribute the burden among all the developers, which would make the whole idea of a Debian Desktop or Debian Jr subproject as being a real part of the main viable. Right now, most users regard them as second tier, if they're aware of them at all. Bringing the subproject idea in as a fundamental part of the infrastructure, at least as fundamental as the different branches, would probably help to improve them on the whole. > > > There are other sorts of decisions we can make as a class for our users. > One is for i18n. If you're from France, then it's probably obvious what > your timezone is, what your preferred language is, what character set > and keyboard you're using, and that you'd like the -fr version of any > documentation packages installed. If you're a C developer, you probably > want the lib*-dev versions of any lib* packages installed. For perl, > lib*-perl, for python, python-*. Another example is for common sorts of > computers: if you've got an Apple iBook, there are only a few ways you > want to configure X, you want USB and IEEE1394 configured, you want a few > extra packages installed to make some of the special keys work and get > power management working, you probably want to be prompted on what keys > to use for middle and right mouse buttons. These might or might not be > "flavours". They might or might not be managed using similar technology > to flavours. That brings up another idea. Tiered flavors, which are customized the same way. Someone choosing the "home user" flavor might not be offered any more significant choices, the would just have some apps installed by default for them. However, someone who chose the developer environment would then be offered the choice of C developer, LISP developer, etc. These tiers would be customized depending on how advanced the user is expected to be (developer, server, etc being offered more fine choices than the home user or the router flavor). This could all be done by the same sort of mechanism as described above, tailored debconf questions as determined by the current context. > > > In some cases, we already do this sort of thing. We usually make the > decision "If you install this package, you want it operational and > available" for our users, eg. We have various tools to automatically > write various config files for us. We have tasks to help us get some of > the package sets we want. > > The issue, I guess is something like: > > * Centralising the decision making for various issues, so you > can make a single obvious decision where you currently have > to make a multitude of subtle ones I see the most central decisions being made in a tasksel sort of way, perhaps with policy as a backup to determine which flavors are officially supported. Beyond that, in terms of the multiple subtle decisions, that should be left to the individual pacakgers. > > * Making it possible to burn particular decisions onto a CD to > give to someone, without having to make that decision for > everyone who uses Debian I'm not sure as to how exactly to achieve this, but I can't imagine it's so hard. Debconf already has this sort of stateful database. Using it in combination with something similar would probably yield a workable solution. > > I don't know how we'll achieve that. Nor I, ultimately. But I'm going to think about it some more and I'm looking forward to hear other people reply to your mail and this one. - David
Attachment:
pgpoh0pq9XGpd.pgp
Description: PGP signature