On Thu, 2003-12-04 at 11:42, Zenaan Harkness wrote:
> I could almost cut and paste your email into the wiki it was so clear
> (at least Debian parent(super) project -> CDD -> Flavor).
>
> I hope I haven't misunderstood you,
No, I was just in a hurry and expressed myself inadequately.
The discussion and presentation of the three layers was, however, just a
step in the process. Now that many people on this list have expressed
their (mostly positive) opinions -- many more could comment still -- and
there has been a proposal of what first actions should be taken -- work
on the Subproject HOWTO -- I think the next set of questions lies ahead.
As Andreas Tille said, and I agree, this borders on a stupid naming
discussion
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00338.html). However, there's a reason why it isn't that after all.
Think of these terms as labels or abstract ideas that have a concrete
counterpart -- an implementation, if you will. Mako Hill said of the
2003 Debcamp Custom Distribution BOF:
"I think we left with the idea that "flavors" or "metadistros" and the
like may still describe *technologies* or methods which one could use to
achieve a Custom Distro."
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00367.html)
This is exactly what I was thinking, and I also think that a kind of
understanding about all this has existed for some time. Someone just
needs to s-p-e-l-l it out even when the explanation borders on
stupefaction for those who have already given it lots of thought.
So, mapping the terms "Debian subproject", "Custom Debian Distribution",
and "flavor", to their concrete counterparts, I get:
Debian subproject
* A group of people.
* A mission or goal that is a subset of the whole project's
mission.
* A mailing list -- possibly.
* A web site [within the main Debian site] -- possibly.
* A repository for code or files -- possibly.
* Other things depending on the project.
Custom Debian Distribution
* A Debian Subproject.
* The goal is to create a variant of Debian for a specific
purpose, but utilizing the Debian development framework and
resources, and feeding back* the work into the super-project.
(* Perhaps this is slightly misleading. A major portion of the
work will of course be done within the super-project itself.
Some things, however, will first see its light as a solution for
a specific Custom Debian Distribution. The goal then is to make
the solution general enough for use in the super-project, if
this is at all sensible. It's an evolutionary process.)
Flavor
* A set of predefined choices applied to a Custom Debian
Distribution, making different flavors of the same Custom Debian
Distribution slightly different in some respects.
* A way to differentiate different parts of a distributed system
that logically belong to the same Custom Debian Distribution --
several installations that cooperate to create a larger whole.
* A set of install-time choices and actions that alter the
installation procedure.
* A set of packages that are automatically installed and
configured, possibly with some variables set by a user.
By looking at this, I see lots of open questions and tasks that need to
be carried out for all three areas.
For subprojects, there needs to be a way to determine if something is an
official Debian subproject. I think being listed on what is currently
http://www.debian.org/devel/, under the heading "Projects", would be the
indication of this. The rest is work on the Subproject HOWTO and
possible further discussions that are best deferred until the work has
started and the issues come up.
For Custom Debian Distributions, little needs to be done. This indicates
the term is successful and clear. The Subproject HOWTO should include
something like the above definition. Perhaps more detailed, but ok.
For flavors, there is heaps of work to be done. In another thread,
Andres Salomon said, among other things along the same line:
"...should be concentrating on the framework that will make flavors
possible. There is much that remains to be done on the technical
level..."
(http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00393.html)
I see flavors manifesting themselves technically in two places:
* In the installation procedure of Custom Debian Distributions,
probably as hooks and/or udebs for debian-installer.
* In the package pool, as packages which are built general enough
to support pre/postinst configuration by the above method, and
as both new and special versions of certain packages.
* As tasks and metapackages. Tasks could be hierarchial to support
the structure discussed in this thread.
One final semantic thing about flavors that I would like to propose: the
"plain" flavor. The definition is obvious. It's what you get when not
specifically choosing a flavor. Currently, only the plain flavor of
Debian or any of its Custom Distributions exists.
There is an enormous amount of things that can be drawn from this, and I
have many more thoughts. But I'll stop here for now.
I welcome all to discuss!
Cheers,
--
Fabian Fagerholm <fabbe@paniq.net>
Attachment:
signature.asc
Description: This is a digitally signed message part