[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Examples for CDDtool

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 }" 
>      | 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
  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.



  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

    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

Reply to: