Thanks for replying Andreas! I appreciate your feedback. On Mon, Sep 27, 2004 at 09:54:40AM +0200, Andreas Tille wrote: > On Fri, 24 Sep 2004, Benj. Mako Hill wrote: > > >article to this email. Feel free to follow up here. > > > >You can also read that piece and leave comments on my blog: > > http://mako.yukidoke.org/copyrighteous/freesoftware/20040924-00.html > I feel free to also quote this URL here and hope this is fine... Yes, absolutely. Please do. > > * Package selection: Which software in Debian does the deriver want to > > include? > > More or less equal to meta-package dependencies even if there was > some discussion about constraints of meta-packages which might be > solved by Debtags (which is surely right) I have no better > *currently working* solution. That's true for the groups working inside Debian politically. Derivatives that aren't politically connected to Debian don't necessary seem to be going the metapackage route. Tasks are one option and there are others. > > * Package configuration: What configuration changes does a deriver > > want to include (anything you can do with debconf/cfengine)? > > Could be done to some extend by pre-feeding debconf questions. We > could even deliver cfengine scripts which can be run by the local > admin but the question of upgrades is not solved here Right. If it makes it easier, I'm happy to assume the existence of a CDD over time (even though this will not always be the case). I'm also happy to have a constraint be that a CDD only needs to Just Work when it's installed as a CDD and then upgraded as one. I see no need to support upgrades from Vanilla Debian to CDD-X or from CDD-X to CDD-Y even if it would be cool and useful and a goal for the future. Does this make the upgradeability question more simple? > but this is partly no real difference to normal Debian packages > because we discussed that the upgradeability is not always given > anyway (i.e. discover1 -> discover2 changed config file format) Breaking upgradeability may not be unheard of in Debian but it's certainly rare -- and for good reason! :) > > * Package replacement (for lack of a better term): What packages > > does a derivative want to ship that has diverged from the package > > in Debian in terms of code (bug fixes, features, whatever)? > > While I think that the three points you mentioned are a very good > summary of the CDD issue I'm not sure whether this can (should) be > done inside Debian. Debian-NP already has packages (postfix for example) that, at least the moment, are sufficiently diverged from the Debian package that we kept them as separate packages in a separate repository. I think most CDDs do this. This *will* be desirable even for projects who are politically located within the Debian project. It's the one area that's not really been discussed in the CDD community so far to a lot of depth. I think it's worth thinking hard about our options here even if the conclusion is that its not in the scope of the CDD project. :) > >This creates problems and uncertainty that we in the CDD community > >has been grappling with for a long time: Is Debian-Nonprofit > >Debian? Can any CDD really be Debian? > > My answer to this is contained in most of my talks (also the > Florence talk at: > > http://people.debian.org/~tille/talks/200409_florenz_user/index.html#WhatCDD ) > > Basic idea: > Do not make a separate distribution but make Debian fit for > special purpose instead I've certainly heard you say this and I've said it myself many times. I agree. I think you might be missing the point I was trying to make here though. The fundamental point I was grasping for was that this idea of customizing Debian or working within Debian is a highly complex issue grounded on this idea of "what is Debian?" Answering that question is a political issue, a technical issue, an organizational issue, and an ethical and philosophical issue and the answers are not clear and "making Debian fit for a special purpose" is extremely difficult until you know where the lines that "Debian" are. My point was that the answers to this question, and the fixation on this question, can serve to reduce the level of collaboration between groups that are inside Debian and groups that are outside. The reality of the situation is that we are having people that are diverging form Debian to a series of degrees. All are organizationally and political distinct to different amounts. From the technical perspective, we have folks who on the one hand are uploading new packages focused at a particular group and we've got other projects that look and act a whole lot more like forks but who want to give back -- and we've got many people in between. Not everything that Ubuntu or Debian-NP does will or can be brought back into Debian as it is defined in a narrow technical sense at the moment. That's the reality of the situation. I think we have the opportunity to define technical and social system for sharing and collaboration on an inter-project basis within Debian that includes groups that are not within Debian -- Debian the project, not necessarily Debian the distribution as it is defined right now at ftp.debian.org. > So I'm not sure whether *any* CDD really be Debian, but all those > who decided to follow this idea of a CDD can, IMHO and per the > definition we agreed to. Sure! :) > IMHO we would have less problems if we would try to relay on a > common tool set which technically glues together what is separate in > terms of the target user group. I'm absolutely convinced that > relaying in common tolls will show whether it is possible to go > together or if everybody tries to go their own way. My main concern > about all CDD stuff I did (docs and cdd package) was to get people > involved and just to *use* these tools. I'm absolutely convinced > that there are many things to enhance and the current state has > drawbacks. I think a good place to start is to look at what people are using instead to solve the problem/goals that I described above and find out why they are not using the CDD infrastructure. You seem to be doing a good job of that already! :) > Before I went to Florence I asked here whether somebody is using the > cdd-dev package. Right. I read this thread. > I try to give a summary of the answer which is more or less > symptomatic. Later I give some technical comments to these answers. > > 1) I use a slightly hacked version. > 2) We also tried debtags and we planned to build the metapackages from the > debtags database. > 3) I didn't use cdd-dev but thers ways to do the same. > 4) Joey Hess recently modified the debian-edu meta package build system > and tasksel to support custom tasks > > You obviously see that there are at least four drawbacks of the > current cdd-dev package (or at least there are people who refuse to > use it because they see drawbacks for their special work). I think we need to evaluate which of these are really bad things. Is having people use custom tools to customize Debian really bad? I think it depends more on the amount of collaboration and the amount of sharing between projects that should be the real evaluation criteria. > As I said I try to come up with an updated doc at the end of this > week and try to answer some open question from this mail. Please > support me with your input. Great! I hope my input so far has been helpful. :) Regards, Mako -- Benjamin Mako Hill mako@debian.org http://mako.yukidoke.org/
Attachment:
signature.asc
Description: Digital signature