Re: Feedback about the cdd-dev package and more...
|--==> Sergio Talens-Oliag writes:
ST> [1 <text/plain; us-ascii (quoted-printable)>]
ST> 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.
ST> 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.
ST> Well, I believe that now we are in a better position than before, I don't
ST> want to force anyone to work as I want, I want to integrate the techniques
ST> already on place and build common tools to handle them, simplifying things
ST> as much as possible.
ST> I need to work on cdd-dev to build my own CDD, what I'm looking for now is a
ST> consensus on what is needed and how to store the information, once that is
ST> agreed on I can build or improve current tools for my pourposes, but
ST> including what others request.
ST> My proposal can be sumarized as:
ST> - We need a system to store tasks, or components, or whatever name people
ST> wants to give to a system to select a group of packages and configure
ST> them using debconf pre-seeding and postconfiguration scripts.
Yes, that's correct.
ST> - I want to work on it and, right now, I only need to standarize and
ST> document the way we want to store the input data and what is this input
ST> data.
ST> My current proposal is to put all files related to a 'task' inside a
ST> directory; currently I have three different kind of inputs:
That was my idea to up to some months ago, see the structure outlined in:
http://lists.debian.org/debian-custom/2004/04/msg00156.html
near the half of the message.
However I have to say that now I found more comfortable to manage
single files.
Thinking in terms of tags, a task shall be considered a tag applied to
a certain package.
For example I've wrote a little vocabulary for demudi task-tags:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0
which is contained in a single file, and then used the defined tags to
mark packages:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagpatch?op=file&rev=0&sc=0
Personally I find more comfortable having a single long list of
packages, alphabetically sorted with tags attached. This way it's
straight to check if a package is present or not, which task it
belongs to, move one package from one task to another etc.
Splitting the tag definitions (the vocabulary) from the tag
application also allow to insert package specific information.
For example I've add a "relevance" tag which is used to distribute the
packages in CD collection (mycdd-CD1, mycdd-CD2, etc). This way if you
want a minimal system you just use CD1, otherwise you can get more
packages.
Note also that in the vocabulary:
http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0
there is a Relevance: stanza which has a different meaning than the
"relevance tag". It applies to the task/tag as a whole rather than to
a single package, and it's used to order the task list when displayed
when you launch tasksel.
Another package specific information it's menu entry. We can add a
"menu" tag to specify the location of a package in the menu tree. Note
that the mere information of which task the package belongs to it's
not sufficient for this, unless you are happy with 1-level deep menu
trees or you introduces sub-tasks, sub-sub-tasks etc.
So splitting tags definition and application makes sense to me.
Moreover this way you preserve full modularity. That means if you want
to distribute the task information in different directories you can
still do it, a script can collect them together. On the other hand if
you force a directory based approach some people (me :)) may not like
it.
So my proposal is to use a tag oriented approach. We just have to
define two formats:
1) how to define a tag
2) hot to apply a tag
these are different type of data which shall go in different
files. The number and hierarchy of such files is left at your taste.
Then the semantics of a certain tag (e.g. task, menu, priority) is
obviously defined by the scripts which parse the data files.
As far as tag definition is concerned I'd I'd use the debtags format,
which is basically identical to the one currently adopted by cdd-dev
and described by Sergio.
However I'd distinguish two levels.
1) A "raw" tag definition level, that is typically used by a little
parsing library. At this level a the format is very loose, roughly:
Tag: type1::name1
Field1: value1
Field2: value2
Tag: type1::name2
Field1: this field has a very long
value so that I need another line, prefixed by a space
Field2: value2
Tag: type2::name1
Field1: value1
Field2: value2
Of course you can have as many fields you want. A tag definition
ends with black line. The parser library would return the list of
defined tags along with their fields-value associations.
2) A tag specific definition, whose fields depends on the tag semantic, e.g.
Tag: task::mytask1
Description: this is my first task
Relevance: 9
Confilcts: mytask2
Depends: mytask3
Action: mark
this tag defines a task which will be displayed by tasksel among
the first ones (Relevance 9) and that on new install will be marked
for installation by default when the tasksel dialog appears.
Tag: menu::mypath1
Path: Some/Custom/Path
this tag defines a menu path.
Tag: preseed::mypreseed1
File: /path/to/values
Then you can have one or multiple files containing tag applications:
pkg1: task::mytask1, menu::mypath1, preseed1::mypreseed1
and there will be a couple of scripts which will parse it (for example
when tasksel is invoked or when update-menus is invoked, these two
programs provide hooks to achieve this).
Well, this are rough idea, need to be elaborated..
Cheers,
Free
ST> - package selections: we can keep using the same format being used now, a
ST> pseudo control file that includes the following fields:
ST> - 'Task': mandatory (could be taken from the directory name)
ST> - 'Description': mandatory (useful and needed for metapackages)
ST> - 'Architecture': optional, defaults to 'all'
ST> - 'Section': optional, defaults to 'misc' (well, I have to check that)
ST> - 'Depends', 'Recommends', 'Suggests': At least one of them is required,
ST> they list the packages we want to include and can be present multiple
ST> times to be able to add *meta-information* for each dependency
ST> (debian-edu adds fields like 'Why', 'Responsible', 'URL', etc.).
ST> The name of the field will imply the same as on the control file, and
ST> will have different effects depending on the target system (i.e. for
ST> tasksel recommends and suggests can be put on diferent tasks, to be
ST> able to not install them)
ST> - 'Avoid' (I'll prefer 'Conflicts'): This should not be needed, but
ST> maybe is interesting to be able to declare explicit conflicts ... we
ST> have to discuss it further.
ST> I propose to add some extra fields to declare inter-task relationships:
ST> - 'Depends-Task', 'Recommends-Task', 'Suggests-Task' and
ST> 'Conflicts-Task': Those fields declare relations between the CDD
ST> tasks.
ST> And use the prefix 'X-' for all not defined fields (i.e. I would change
ST> the debian-edu 'Why' fields per 'X-Why', just to be able to verify the
ST> sintax of the files and ignore all 'X-' fields).
ST> - preseeds: I will put debconf presseds into two subdirectories of the
ST> task directory (one for the system debconf and another for the installer
ST> debconf). My original idea is to concatenate all files present to
ST> generate a simple preseed, but maybe we should support a richer format
ST> to be able to decide if a preseed has to be applied or not (i.e. if we
ST> have presseding for Suggested packages maybe we don't want to apply it
ST> on some cases). Has to be discussed.
ST> - postconfig: Similar to the pressed case, the idea is to include all
ST> scripts present on a directory and execute them in order after
ST> installation.
ST> - Once the formats are clear and we have the tools a CDD can be defined by
ST> those files and distributed *in source* form (all the files I'm talking
ST> about could be installed into /usr/share/cdd/cdd-name/ and be used
ST> by the cdd-tools to generate metapackages, tasks, tagfiles, ... and build
ST> cdd apt repositories, generate debian-installer images or live cd versions
ST> 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 :)
ST> Well, I'm open to cooperation, once we agree on the formats we can try to
ST> join forces and do testing toghether ;)
Reply to: