El Thu, Dec 02, 2004 at 01:32:46PM +0100, Andreas Tille va escriure:
> On Thu, 2 Dec 2004, Sergio Talens-Oliag wrote:
>
> >El Wed, Dec 01, 2004 at 10:33:40PM +0100, Enrico Zini va escriure:
> 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 ...
As I understand it, the script is work in progress and is available in the
debian-np subversion repository, so I see no problem with it, in fact I
prefer to put it inside the cdd-tools framework when it is ready, to avoid
half implemented features on the releasable package.
For me the most important thing is to avoid, as much as possible, the effort
duplication, and for that a simple mail to this list is enough (well, and
maybe an update to the cdd-doc to say what features are being developed and
an URL to get in touch is also a very good idea also).
> >>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?
Well, I have the feeling that the problem is, as Enrico said, that everybody
is quite busy and a lot of projects were already in development when you
started to work on the cdd package and now maybe they don't feel like
changing.
My advantage is that I'm starting now, have more needs that Debian-Med and
probably will have time to develop, so I, for sure, will try to cooperate
and get feedback.
> 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'll try to do it and will send feedback to this list.
> 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).
Hmm., now it is too soon, but when I get to this part we can talk about it.
I'm also interested on user menus and roles, but we are solving it for a
different environment (GNOME Menus Only) and we are solving it now at
installation time (putting files in /etc/skel and adding system menus),
anyway I would love to have a general solution, I'll think about it when a
lot of other things are finished ... ;)
> > 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...
OK, I'll try to, maybe we should send a call for cooperation to all the
people interested on CDD, I thought this list was the one, but maybe I have
to post to debian-devel and all the current custom distributions lists...
I'll do it tonight.
[...]
> 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.
Well, I don't have strong feelings about it, it's simply I have the feeling
that it is cleaner to put all the things related to a task together, and
once the layout is clear and documented a migration should be a matter of
minutes ;)
> 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. ;-) )
Well, maybe on the next meeting that could be arranged... ;)
> > - 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.
Well, again I don't have strong feelings, but I believe that a structure
like:
cdd/
task1/
package-selections/
debconf-pressed/
installer-pressed/
postconf-scripts/
Makes working on a task cleaner and more extensible: the idea is that each
file inside a directory can be handled by different people, something that
is very interesting (and I plan to use) for preseeds and postconfig
scripts, mainly because they can be logically related to a single package
or a small set of packages.
Note that I've also put the package-selections/ as a directory, I believe
that we only need one file, but maybe is not a bad idea to allow multiple
files for the same reasons as I've given for the preseeds and scripts.
> > - 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.
First I have to say that with source package I mean the distribution of a
.deb that contains the task directories as I've described before.
Distributing the CDD in this way allows anyone to generate a CDD repository
or installation CD using sarge, sid or whatever mix he wants to, without
introducing dependencies into the main Debian archive.
Of course if you want to include metapackages into the archive you can do
it, but that's only for convenience and is probably easier to generate the
metapackages localy and put them on people.d.o or alioth.d.o for the
different debian releases.
--
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