El Wed, Dec 01, 2004 at 10:33:40PM +0100, Enrico Zini va escriure:
> On Wed, Dec 01, 2004 at 08:43:46PM +0100, Sergio Talens-Oliag wrote:
>
> > Comments? Suggestions? Flames?
>
> Everyone wants to specify all the CDD data in a single place, and I
> think everyone is kind of doing it in a way or another.
OK, so we agree on that!
> For example, the new supersimple-cdd-building-script from Vagrant (that
> I'd like to see into cdd-dev soon, if possible) does it. Free told me
> he's doing something like that as well. Everyone is.
>
> I think everyone of us created some code that in some way overlaps with
> what the others have done, and I think we share at least the goal of
> having a CDD description somewhere, then running make-cdd and have the
> ISO images built.
>
> So, the question is: why don't we have that already?
>
> My bet is that if we create a common standard, then for it to be adopted
> everyone needs to change the way they work. This is of course a burden:
> it means asking too much to busy people working hard on their agendas.
Well, I believe that now we are in a better position than before, I don't
want to force anyone to work as I want, I want to integrate the techniques
already on place and build common tools to handle them, simplifying things
as much as possible.
I need to work on cdd-dev to build my own CDD, what I'm looking for now is a
consensus on what is needed and how to store the information, once that is
agreed on I can build or improve current tools for my pourposes, but
including what others request.
My proposal can be sumarized as:
- We need a system to store tasks, or components, or whatever name people
wants to give to a system to select a group of packages and configure
them using debconf pre-seeding and postconfiguration scripts.
- I want to work on it and, right now, I only need to standarize and
document the way we want to store the input data and what is this input
data.
My current proposal is to put all files related to a 'task' inside a
directory; currently I have three different kind of inputs:
- package selections: we can keep using the same format being used now, a
pseudo control file that includes the following fields:
- 'Task': mandatory (could be taken from the directory name)
- 'Description': mandatory (useful and needed for metapackages)
- 'Architecture': optional, defaults to 'all'
- 'Section': optional, defaults to 'misc' (well, I have to check that)
- 'Depends', 'Recommends', 'Suggests': At least one of them is required,
they list the packages we want to include and can be present multiple
times to be able to add *meta-information* for each dependency
(debian-edu adds fields like 'Why', 'Responsible', 'URL', etc.).
The name of the field will imply the same as on the control file, and
will have different effects depending on the target system (i.e. for
tasksel recommends and suggests can be put on diferent tasks, to be
able to not install them)
- 'Avoid' (I'll prefer 'Conflicts'): This should not be needed, but
maybe is interesting to be able to declare explicit conflicts ... we
have to discuss it further.
I propose to add some extra fields to declare inter-task relationships:
- 'Depends-Task', 'Recommends-Task', 'Suggests-Task' and
'Conflicts-Task': Those fields declare relations between the CDD
tasks.
And use the prefix 'X-' for all not defined fields (i.e. I would change
the debian-edu 'Why' fields per 'X-Why', just to be able to verify the
sintax of the files and ignore all 'X-' fields).
- preseeds: I will put debconf presseds into two subdirectories of the
task directory (one for the system debconf and another for the installer
debconf). My original idea is to concatenate all files present to
generate a simple preseed, but maybe we should support a richer format
to be able to decide if a preseed has to be applied or not (i.e. if we
have presseding for Suggested packages maybe we don't want to apply it
on some cases). Has to be discussed.
- postconfig: Similar to the pressed case, the idea is to include all
scripts present on a directory and execute them in order after
installation.
- Once the formats are clear and we have the tools a CDD can be defined by
those files and distributed *in source* form (all the files I'm talking
about could be installed into /usr/share/cdd/cdd-name/ and be used
by the cdd-tools to generate metapackages, tasks, tagfiles, ... and build
cdd apt repositories, generate debian-installer images or live cd versions
of the cdd).
> How to overcome this? I don't know yet.
>
> An idea in my mind would be that since in Debian-NP we're thinking of
> not being a CDD, but rather a group helping people in making their own
> CDD, we are the perfect opportunity to spread what we agree is the best
> and more comfortable way to do things.
>
> Once some way of doing things is spread and gets more mature, it can be
> considered a better replacement for some hacked script that one is using
> and has not time to improve.
>
> Better ideas are however quite welcome. Also because in Debian-NP we
> have rather unpredictable times :)
Well, I'm open to cooperation, once we agree on the formats we can try to
join forces and do testing toghether ;)
--
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