Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2003-12-05 17:13, Ben Armstrong wrote:
> On Fri, Dec 05, 2003 at 09:23:52AM -0600, cobaco <cobaco@linux.be> wrote:
> > On 2003-12-05 11:06, Andreas Tille wrote:
> > >Debian-Edu *is* a CDD because
> > > it is completely inside Debian and
> >
> > hm, as far as I know Debian-edu is nothing more then a couple of
> > task-packages at this point (and some education packages that got added
> > to the archive)
>
> Which doesn't change Andreas' point. It may be a lame CDD, but it is
> still a CDD. :)
in my view a CDD should provide
1. a (sub)set of packages
2. a default configuration of these packages fitting the target group of the
CDD
Debian-edu (pre-merge with Skolelinux) got started on 1. but never got around
to 2. Thus I'd call the debian-edu task-packages a first step to a CDD, but
not a CDD (as 2 is missing)
> > > the suggestion is that SkoleLinux
> > > people patch the packages according to their needs.
> >
> > being done for Skolelinux, so basically you're saying that Skolelinux
> > (or any other project aiming to be a CDD) is not a CDD untill they get
> > everything they need back into Debian proper (which can take quite a
> > while), even when we're trying to do so (and always have)?
>
> Again we trip across the distinction between organizational and technical
> terms. Skolelinux has not yet produced a CDD release (the technical
> term), but it is a work-in-progress. Organizationally, Skolelinux is a
> subproject that is working to produce a CDD because that is its stated
> goal.
> > >The *product* (one
> > > bootable CD) which contains Debian-Edu plus some extra packages which
> > > are necessary for whatever reason might be called SkoleLinux but this
> > > is not a CDD per the definition I was using in my talk in Oslo. There
> > > was nobody who disagreed ...
> >
> > hm, the definition I was using for a CDD would include Skolelinux
> > because while not everything we do is in Debian _yet_we are trying to
> > get everything included into Debian.
>
> Sure, the work-in-progress is a CDD. Existing releases, however, are not.
Ok, so right now we have a number of sub-projects working to produce a CDD
but no actual CDD's (since not all the necesary parts to create a CDD are
available in Debian).
> I still have a problem with "whenever possible". You seem to be reserving
> the right to always include some material in releases of the CDD that is
> outside of Debian. You cannot call any release of Debian including
> material outside of Debian main "Official Debian". That isn't just
> splitting hairs. That's how it is described here:
>
> http://www.debian.org/CD/vendors/
>
> Depending on whether you are talking about a CD of Skolelinux as a stable
> or developer's release, it is either a "Vendor Release" or "Development
> Snapshot" according to the descriptions on this page.
ok that's clear now: in order to call something a CDD everything it uses
needs to be inside Debian because otherwise the "Debian" needs to be left
out of CDD (which would leave CD, and that acronym is already taken).
hm, so
CDD = a subset of Debian configured to work for a particular target group
out-of-the-box.
should probably be added to the CD types once actual CDD's come into
existence.
that is if there's nobody who has problems with the above definition.
> > The important point here is, IMHO, that
> > there is effort to get the missing pieces into Debian. Wether all pieces
> > are already in Debian at a given point in time is I think unimportant
> > (for defining a CDD anyways).
>
> For defining a subproject working on a CDD, no. But intent doesn't make
> any difference to the end-user if release time rolls around and stuff
> outside of Debian is still being included. At this point, what the users
> have in their hands is a distribution derived from Debian. For example,
> if they find bugs in any of the material outside of Debian, it must be
> dealt with outside of the usual Debian structures (i.e. bts makes no
> provision for filing bugs against packages that aren't actually in
> Debian).
ack, clear now.
- --
Cheers, cobaco
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/0TEd5ihPJ4ZiSrsRAvoiAJ9skI3zIwUNAl3pO6Ky1Lw/mDdV9wCeOIh2
0UFNVLMhsauZR0eIzjxxuQ8=
=H7Id
-----END PGP SIGNATURE-----
Reply to: