Re: Feedback about the cdd-dev package and more...
On Thu, 2 Dec 2004, Sergio Talens-Oliag wrote:
El Wed, Dec 01, 2004 at 10:33:40PM +0100, Enrico Zini va escriure:
Upps, I did not recived the mail which was quoted ... ???
For example, the new supersimple-cdd-building-script from Vagrant (that
I'd like to see into cdd-dev soon, if possible)
It is definitely possible. I'f I'm not completely wrong you (Enrico) have
administration rights in CDD alioth project. Just add Vagrant and he is
able to check in his (mysterious?) script. Working like this was my intention
when the project was created. We are so many people doing fine stuff. I
would love if someone could explain me why there is an imaginary hurdle
before the SVN archive that people do not check this in ...
does it. Free told me
he's doing something like that as well. Everyone is.
This "everyone is" sounds really strange to me. I wonder if there is some
reason that people who work on Free Software and did obviousely understand
how shareing work works don't share their work in this special case. Is it
the fact that cdd-dev was derived from a not so developed CDD like Debian-Med?
If this is the case I repeat: I'm able to adopt to any change with my
small little project (compared to Debian-Edu and others I do not know so
detailed). If there are requirements for a change of the current state -
just do it (AND DOCUMENT IT). I will follow for the sake of a common toolset
and for finaly having much less work than we have now.
I would volunteer to keep the user menu part in sync with the changes
because this is the part I'm keen on (and were I wonder why others do
not, but this is not my problem).
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?
I guess if we start now we could have a common Christmas gift. :)
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.
So as written above: I offer to follow a standard which is defined by
somebody else. I moreover offer to also keep Debian-Jr in sync with this
new standard because it is quite similar to Debian-Med and I offered to
Ben to care for the move to cdd-dev.
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.
This is fine. I guess the cruxial thing is to convice the remaining part.
My idea was to change as less as possible to the most advanced *official*
(= with meta packages inside Debian) CDD (=debian-edu). I expected to
increase the level of acceptance to switch to cdd-dev. Please make sure
that you get these people into the boat...
- package selections: we can keep using the same format being used now, a
pseudo control file that includes the following fields:
...
- '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.
Interesting functionality which I also thought about.
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.
Good idea.
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).
Makes perfectly sense.
So this proposed additions are fine and do not really break anything compared
to the current syntax (except that we should rename "Why" to "X-Why". Please
think twice about you really need to change the location of the task files into
the directory structure. It is fine for me, but we want to attract *all*
CDDs. You need strong reasons to convince to a change. The beauty of the
directory layout is probably not enough to convince busy people - but it
depends from your talent in discussing (or perhaps offering them some free
Spanish wine at the nect conference in Spain - in the later case I want to
be convinced as well. ;-) )
- 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.
In the sense of above: Please think about it whether a directory layout like
preseeds -+- task1.debconf
+- task1.idebconf
+- task2.debconf
+- task2.idebconf
+- ...
would provide the same functionality but follows the "established" logic.
- postconfig: Similar to the pressed case, the idea is to include all
scripts present on a directory and execute them in order after
installation.
Same as above.
- 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).
Hmmm, I do not really see the advantage to use these files *in source*. While
I would havo no trouble with this I do not see the advantage.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: