Let's move this to debian-custom, as it really has more to do with CDDs in general than Debian Jr. in particular.
On Tue, 24 Apr 2007 08:25:24 +0200 (CEST) Andreas Tille <[EMAIL PROTECTED]> wrote: > Why? You asked here why I say metapackages work well for me. I don't really know what to say. I simply have not had any trouble with them that seemed worth the effort to change. At various times in the project I thought a change was needed, but at this time it works well enough, is simple to look after, and none of my users are telling me "look, this really doesn't work well at all". So, why not? > Well, doing per-user changes is more than a CDD can cope with. It is > just the work of a local administrator - at least if I understand you > correctly. Precisely. Observing my own family, I have found that the work of a local administrator is mostly what is required to keep a system flexible and meeting the needs of all individual family members. Forcing one set of choices globally on the whole family would be the BOFH approach. It might make sense for a workplace, a school or other environment where a system is tailored for one particular purpose, but the home is quite different. In the home we have leisure time to spare, time to pursue enjoying the Debian system in all of its glorious adaptability. I can see the logic in creating an /etc/junior/skel as a starting point for this journey, but not in making debconf and /etc changes that force one set of choices on all users. Even in cases where our users have the luxury of devoting entire systems to use exclusively by children, who is to say that our own choices will reflect the choices of all parents? For instance, while I find the Disneyfication of systems for children repugnant, and therefore have a bias to make a distinctively different Debian Jr. system in opposition to this popular trend, whose interests would this really serve: my users, or my own? I recognize the diversity of values in the families out there who might use Debian Jr. One family wants filtering, another doesn't. One objects to the mild gore xpenguins, another doesn't. I can choose some "safe" defaults for the starting point, but I would rather leave as many options open as possible, making it clear to the children's administrators that it is up to them to assist each child in solving their problems in a way that jives with their own values and that is sensitive to their particular needs. To have this flexibility, individuation not only from family to family, but from member to member within the family is essential, and that means per-user customization. > I'm afraid I do not fully understand your concerns and I even don't > know what you regard as "typical" CDD and what the differences are > between this typical concept and Debian Jr. Could you try to be a > little bit more verbose to let me understand the problem. My concern > is that if there is only _one_ "typical" CDD that uses cdd-dev than > the word "typical" is not used apropriately and this is my concern. Debian Jr.: a home system with a default package selection and some initial default child's accounts settings which then are modified by the administrator to suit their child users as they grow according to their own tastes and values. A "typical" CDD: a Debian system devoted to some particular purpose, tailored by the CDD project to meet those particular needs, where the choices of the CDD project will meet the majority of the needs of their users. It is not that Debian Jr. does not qualify as a CDD, but I actively avoid making choices for the children and administrators as much as possible, preferring instead to keep them well informed about issues and equip them with suggestions for solving their own problems rather than solving them for them. So yes, there is a subtle difference of philosophy here that calls for a difference choice in technology to support it. > IMHO there are two reasons: > 1. If all CDDs have so different needs that there is no chance to > base them on a common toolkit, it makes no sense to continue > development of cdd-dev. That is a large extrapolation from my argument. I have singled out Debian Jr. as different not because I believe *all* CDDs have such different needs, but because of a difference of philosophy that has grown in my mind over the past seven years to the point where I now recognize that somehow my project doesn't quite fit the mold. > 2. The toolkit cdd-dev is just not flexible enough and has to be > enhanced to enable more CDDs that will justify the attribute > "typical". Since you started out saying "doing per-user changes is more than a CDD can cope with," and I have said that making a Debian system truly work well for a child has very much to do with making per-user changes, I don't see what changes to cdd-dev would make it more suitable for use by the Debian Jr. project. That is not to say that none of the issues that CDDs face are of any relevance to the Jr. project anymore. On the contrary, we still have: - an established identity as a distinct group that our users can come to for support, that cares about their needs and works within Debian to meet them; - a selection of packages chosen to be suitable for child users (handled in the project by metapackages, with some notion to also use debtags more intelligently, and perhaps to revisit tasks again); - a live CD / install CD, which most CDDs have and which we are currently implementing built on the work of the Debian-live project; - a growing documentation base (mostly in form of the wiki at the moment, with much more material available to us to fill it out from the collected wisdom of our users over the years in our mailing list archive); - developers who care about the packages we have selected for our users, who keep them in good shape and work actively with upstreams to improve them. I could go on. With little to no technology here that is specific to CDDs, the project does very well to adhere to the core ideals of a CDD. > That's why I'm keen on hearing your opinion about the differences > you see to decide whether reason 1. or 2. applies. In summary, neither applies. Concerning 2, I am sure quite a number of CDDs could use cdd-dev. I am not sure why they have not. There does seem to be quite a lot of re-inventing of the wheel happening here, but this is not altogether unsual for Debian in general. How and why any given package gets attention while other, arguably better designed packages get relegated to the sidelines continues to be a mystery to me. It seems to depend not only on technical excellence, but also on good fortune and the whims and fashions of the day. Concerning 1, I support your efforts with cdd-dev and wish you well. I know you put some effort into the initial cdd-dev conversion of the Jr. metapackages and am sorry we never did use it, but what at the time you did it was probably 90% neglect on my part and 10% doubt about whether the toolkit was going to truly meet our needs has now been dramatically reversed: Debian Jr. is no longer being neglected, and I am now firmly resolved that the technical choices we have made are sufficient for our needs. The rest of the work of the Debian Jr. project will plot a course that veers slightly off from that of the "typical" CDD, while at the same time holding in common with them a shared strong sense of our core principles: that to make Debian work for a particular user population, you need not fork Debian, that everything can and should be done within Debian itself, and that in the end, a CDD is all about doing our best to uphold the social contract with our particular users, not about the particular technologies chosen to do that. Regards, Ben -- ,-. nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] \`' Debian http://www.debian.org [EMAIL PROTECTED] ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
