[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CDD framework funcional needs

El Mon, Jul 11, 2005 at 02:59:53PM +0300, Aigars Mahinovs va escriure:
> While remaking a such framework as the CDD framework the first step
> would be to define the requirements for the functions that the new
> framework would need to have. This will allow us to try to realise,
> what kind of thing will we need for the framework.
> Here are my ideas about it.
> http://aigarius.blogspot.com/2005/07/cdd-ideas.html
> I am now at the speach of Andreas Tille about CDDs and let me dump
> here my idea, what the CDD framerowk should do.

  Take a look at http://people.debian.org/~sto/cddtk/cddtool.html, I'm sure it
  needs a review, but it is a proposal that adresses almost all your summary
  points. I'm working on the implementation of the tool and while doing it I'm
  modifying it's contents.

  My next step, that has started today, is the debian-installer integration.

>     * it should be enough to write one structured text file to create a CDD
>           o you can select a set of packages that are: needed,
> recommended, conflicted;

  That is done on the CDD description file.

>           o you can preseed debconf database with answers;

  The preseedings are not on the description, they are distributed with it but
  on separate files.

>           o you can do some specific changes to the conffiles or other
> files (as diffs or rewrite rules);

  My current aproach proposes the use of scripts to do that, the system
  defines the script interface but does not say anything about HOW the changes
  are done.

>           o you can add/remove some text or binary files;

  Hmmm, the system can be extended to do that, but you should specify more
  what you want.

>           o you can recompile a package (with a patch);

  With the toolkit? Not on my proposal, almost all the work I'm doing is to
  avoid recomplilation of packages, if you need recompiled packages you are
  not on the Custom Debian Distributions area, but on the Derived Debian
  Distributions area.

  And once you recomplile you can apply the customization patches to source
  packages instead of moving files on the installed system as I'm proposing.

>           o you can add some package that is not yet in Debian;

  On the description, of course, but your users will need to use additional
  archives on their sources.list.

>     * the framework can generate a set of packages that could be
> uploaded to Debian, to allow a Debian user to 'apt-get install
> cdd-something'

  I'm already doing this, it is not as automated as I'ld like, but it works.
>     * the framework can generate a simplified installation CD that
> installs the CDD with a minimum amount of questions

  As I've said, I'm working on it. The idea is to generate the needed .udeb
  and use the debian-installer to generate the installer. Probably the full CD
  set will be generated using debian-cd also.

>     * the framework can generate a LiveCD with the CDD

  That is for the future, but if we provide simple system to install on a
  chroot that could be used with almost any LiveCD build system.
>     * a summary of bug reports that relate to the CDD should be gettable

  The idea was to add support for CDD tags on the BTS, but I've also proposed
  ocasions that we should provide a simplified BTS only for the CDD that could
  be linked to and from the debian bts (I was thinking about something diffent
  than debbugs, for example a customized roundup).
>     * all the actions for a CDD should be possible to be done on
> Debian infrastructure. cdd.debian.org portal with standartized
> interfaces for every CDD for documentation, information, bug
> summaries, cvs/arch/svn/... links, links to all CDs, links to web
> forums, ...

  That is possible now, we only need that someone asks for the cdd.d.o
  address, but in the meantime it can be set as a cdd.debian.net system and
  moved later.
>     * all the actions for a CDD should be possible to be done fully
> independently from Debian. Packages for that should be inside Debian
> and should be easy to install/configure

  Your second sentence is clear, but I don't understand your first one, what
  do you mean with 'should be possible to be done fully independently from

>     * a CDD must be able to do releases independantly from Debian

  Here you have an important point, we need DAK support for CDD if we want
  only one Debian pool or to use another system to handle CDD archives.

  Right now almost everybody works building their own archive outside the
  Debian infrastructure, but maybe a common system for handling a pool that
  could be shared between all the CDD would be a good idea.

>     * the should be a way to do security updates for all relased CDDs
> for some fixed time period

  That's the same point as before, we need DAK support or a CDAK (Custom
  Debian Archive Kit) that provides a security archive for each CDD.
>     * any CDD could be derrived either from plain Debian of from any other CDD

  Sure, a CDD can be derived from another CDD, but I don't see the advantage,
  if a CDD is a subset of another it can be included as a flavour on the
  original CDD.

>     * The feature set must be complete enough to have Ubuntu as a CDD

  Impossible, or at least absurd, at least as things are going now.
  Ubuntu is not and will never be a CDD, they are a derived distribution with
  it's own developer community and infrastructure to do almost everythig
  (different bugtracking systems, different autobuilders, etc.), so it makes
  no sense to try to provide tools for them to be in Debian when their main
  idea is to be outside it (nothing wrong with that, Debian is free software).



Sergio Talens-Oliag <sto@debian.org>   <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69

Attachment: signature.asc
Description: Digital signature

Reply to: