El Wed, Jun 29, 2005 at 09:56:54PM +0200, Andreas Tille va escriure:
> On Tue, 28 Jun 2005, Sergio Talens-Oliag wrote:
>
> > More news soon, back to coding... ;)
> I just had a look into your examples and want to give some comments.
> At first I want to say that you did a great job!
>
> Now the comments:
>
> 1) I really like the switch to cdbs!
> But why did you put some scripts to debian/build-tools of
> your actual CDD? IMHO these tools can be used in common to
That was a temporary solution, I wrote that scripts to do things quickly
without touching the cddtk code, but my idea is to remove them and put the
functionality on the cddtool.
> all CDDs. This would only require a minor change. The only
> special thing is how you obtain the name of your CDD
>
> CDD=`sed -n -e "/^Package: .*-cdd$/{ s/^Package: \(.*-cdd\)$/\1/; p }"
> $CONTROL \
> | head -1`
>
> It depends from the fact that the name of your CDD ends with "-cdd".
> My personal opinion is that a CDD should not contain "cdd" in its
> name. You as a man has also a name different from Sergio-man
> (except like those strange things like Superman, Spiderman or
> Batman ;-) ).
Well, the ``-cdd`` suffix comes from doing things in a hurry and not looking
back.
I want to get all the information of the CDD from the description file and
the files already needed and ``debian/control`` seemed the good source for
the CDD name, but I used the ``Package:`` field when my CDD was using only
one metapackage, and when I switched to multiple tasks I fixed things using
the as CDD name the first Package with the ``-cdd`` suffix, that is
oviously a bad solution.
The good long term solution is to use the ``Source:`` field for the CDD name.
For the current scripts it's enought to replace the CDD asignment with:
CDD=`sed -n -e "s/^Source: \(.*\)$/\1/p" $CONTROL`
> But because you depend on a name to find out the CDD name we have to
> find
> out another way. My suggestion would be to source a file like
>
> build.conf
>
> which should be contained in every CDD source file and which would
> open some additional options.
> In any case we should put the common code of both scripts into a
> separate file and source this.
As I said, all that is done on those scripts would be included on the
cddtool, but I don't know if I'll use the current model or a different one,
we can talk about it.
The main problem is that I don't want to build the metapackages with the
main CDD package; the idea is use them to resolve dependencies (something
that can be done without actually installing them) and to install
configuration files (those can be distributed with the cdd package and
moved to the right places if a task is enabled, keeping all the CDD data
only in one package).
Anyway I'm still thinking about how I plan to do things and I've already
uploaded a simple script to build empty packages to the ``cddtk/scripts``
subdir that can be used to build metapackages on the local machine using
only a binary package control file as input.
> 2) I wonder if you do not want to implement a replacement for the
> cdd-common package. The main issue of this package is the
> code which is necessary to implement the user menus. If you
> don't mind I try to add this code to the cddtool package. It
> will not hurd your stuff because we can implement it this way
> that the dependency will not be included if no user menu should
> be included. But in my opinion the user menu is a very good
> way to support users and I would regard it as reasonable for
> any CDD.
>
> What would you think about this?
Sure, feel free to implement the support as you see more appropiate. My idea
is that the menu thing is on the configuration space of the CDD, so probably
the right thing to do would be to distribute the menu information for each
task with the description and provide a script on the lliurex-runtime system
to enable those menus when a task is enabled.
BTW, update your repository and take a look at the runtime system, it is not
finished (the scripts cddtk-divert and cddtk-cfg are not written yet, I'll
try to work on them this afternoo and tomorrow) but the documentation is
already there... I'll write some examples as soon as I finish the scripts
and start to move our CDD to use them.
Greetings,
Sergio.
P.S.: If someone is interested in looking at the sample package using the
current system I can leave a copy on my server or point you to the lliurex
repository:
deb-src http://www.lliurex.net/archive llx0509 lliurex
I've just uploaded there the latest versions of the cddtk and the
lliurex-cdd packages... ;)
--
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