El Tue, Jul 05, 2005 at 02:49:24PM +0200, Andreas Tille va escriure:
> On Tue, 5 Jul 2005, Sergio Talens-Oliag wrote:
> > The bug is on the blank line between X-Responsible and Depends, the
> > cddtool
> > description works using 'paragraphs' that can start with three different
> > Fields right now:
> >
> > Include -> It's replaced by the contents of the file it refers to
> >
> > Task -> Starts/continues with the definition of a task and can be
> > followed
> > by other Task paragraphs or Package paragraphs.
> Just for my personal understanding: If a "Task" results in a meta package
> what is then a ...
>
> > Package -> Starts/continues with the definition of fields related to a
> > package, the paragraph needs to have a preceding Task to which the
> > Package
> > belongs.
> ... "Package"? A Dependency of the meta package or rather further
> specification
> of the meta package of the given "Task".
The original purpose of the field was to use it to add meta-information
related to packages included on the task, declaring that a set of fields
like Cfg-Scripts, Debconf-Preseed, Pkg-Relevance, Menu entries, etc. are
related to the given package inside the Task.
In practice I'm not using it, as almost everything can be expressed at the
task level (i.e., if preseedings are put next to dependencies the
relationship of the presseding with the packages is clear for a person
reading the description).
Originally the idea was that knowing that a field was related to a Package
was going to be useful (i.e. for upgrades), but unconciously I've been
moving this information to other places, as I've done for cfg-scripts (the
current proposal is available on the cddtk-runtime package or from
http://people.debian.org/~sto/cddtk/cddtk-apt.html).
> > If you want to use blank lines to separate a Task definition you need to
> > start the second paragraph with a Task field with the same name:
> OK. This did not occured to me because I just had one control file per
> task. This would need only one single "Task:" definition per file and any
> specifications inside this file were related to this Task (and in
> consequence to the resulting meta package). So I see your point that in the
> case of the "single description file approach" you need to tag the related
> task. I will keep this in mind.
>
> On the other hand wouldn't it be an option to have a "current task" which is
> valid until there is a new "Task:" definition. Anyway, this is a minor
> thing and nothing we should spend much time on.
Yes, that was considered but I removed it as it seemed more consistent with
the Control file paragraphs idea and to avoid surprises when including files
(with the current system you are forced to declare the task or package you
are working with on each file, avoiding the inclusions of unexpected
dependencies on the wrong tasks).
If you feel it is important we can change it in the future, but once you get
used to the syntax it doesn't really matters.
> > Sure, I'll add an user for you (tillea) and I'll send you a private mail
> > with a password and instuctions on how to change it.
> On the other hand you might think about adding a cddtk tree in the CDD
> alioth project. There is even space next to projects{med,junior} for
> lliurex. Anything against this approach. In this case cddtk would stay at
> the place where it finally belongs to, right?
No, I have nothing against it, it's simply that with the current situation I
have a better access to the server (it's in my house ;), but I can put the
code on alioth if everybody agrees.
The lliurex packages will be kept in our servers, as the svn will be
available from a trac installation with a bugtracker and a wiki. In fact
that's one of my pending tasks for this month, reorganize our internal svn
repository (it is a mess right now) and open various projects inside that
trac installation.
--
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