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

Re: Feedback about the cdd-dev package and more...

|--==> Andreas Tille writes:

  AT> On Thu, 2 Dec 2004, Free Ekanayaka wrote:
  >>That was my idea to up to some months ago, see the structure outlined in:
  >>near the half of the message.
  >>However I have  to  say that now I  found  more comfortable to  manage
  >>single files.
  >>Thinking in terms of tags, a task shall be considered a tag applied to
  >>a certain package.
  >>For example I've wrote a little vocabulary for demudi task-tags:
  >>which is contained in a single file, and then used the defined tags to
  >>mark packages:
  >>Personally I  find  more comfortable  having a  single  long list   of
  >>packages,  alphabetically sorted  with tags   attached. This way  it's
  >>straight  to check if  a package  is  present or  not,  which task  it
  >>belongs to, move one package from one task to another etc.
  AT> Well, your arguing is very interesting, but:

  AT>    - You should have discussed this here.
  AT>    - It would be a good idea document it here.
  AT>    - You will have trouble to convince others if you stay that silent
  AT>      (I assume it is your goal to establish your system for other
  AT>       CDDs as well.)

Yes it's one of my wishes to have this  famous CDD infrastructure, but
at the    same way I  don't   have any really convincing   solution at
hand. Thus I keep experimenting following the paradigm "First Do, Then
Document, Finally Automate".. I'm still at the "First Do" phase! ;)

  >>Splitting  the tag  definitions     (the  vocabulary) from   the   tag
  >>application also allow to insert package specific information.
  >>For example I've add a "relevance" tag which is used to distribute the
  >>packages in CD collection (mycdd-CD1, mycdd-CD2, etc). This way if you
  >>want a minimal system  you just use CD1,  otherwise  you can get  more

  AT> Sounds clever and the *real* advantage of your idea instead of the
  AT>     "Personally I  find  more comfortable"
  AT> argument which is not very catchy for others.

  >>Another  package specific information  it's  menu entry. We  can add a
  >>"menu" tag to specify the location of a package in the menu tree. Note
  >>that the mere  information of which task the  package belongs  to it's
  >>not sufficient for  this, unless you  are happy with 1-level deep menu
  >>trees or you introduces sub-tasks, sub-sub-tasks etc.

  AT> I do understand the problem of sub-grouping menu entries but I do not
  AT> see any hint for a solution.  Did I missed anything?

I'm not sure to understand your doubt,  but my idea is  to apply a tag
to each package which needs a different menu location than the regular


xmedcon: task::imaging, menu::Med/Imaging/Conversion
garlic:  task::bio,     menu::Med/Bio/Molecular

  AT> BTW, the current implementation in cdd-dev for menus allows sub-menus
  AT> exactly in the same way like any valid menu entry does allow this.

  >>Moreover this way you preserve full modularity. That means if you want
  >>to distribute  the task information in   different directories you can
  >>still do it, a script can collect them together. On  the other hand if
  >>you force a directory based approach some people (me  :)) may not like

  AT> While I see both points (tags, directories) as interesting for certain
  AT> reasons I might like to remind you all: We are talking about building
  AT> a set of less than 100 meta packages with probably less than 100 dependency
  AT> informations.  I guess the number 100 is a quite safe estimation even
  AT> for the future.  So I ask you to make not a scientific problem of it
  AT> and get something *working* which all people can agree with.  I have
  AT> no personal feelings about this and would be able to cope with both.
  AT> But I really hope that we will find a common agreement in the *near*
  AT> future and breaking the silence around all these single solutions *now*.

Well, ok  we are talking about "little"  things, but this doesn't mean
that we don't have to do things cleanly and beautifully..

IMO  if we have   not found a common  agreement  yet, is because still
there  is no rocking  solution.

  >>So  my proposal is to   use a tag oriented   approach. We just have to
  >>define two formats:
  >>1) how to define a tag
  >>2) hot to apply a tag
  >>these  are different   type  of  data which  shall  go   in  different
  >>files. The number and hierarchy of such files is left at your taste.
  >>Then the semantics  of a  certain tag (e.g.  task, menu,  priority) is
  >>obviously defined by the scripts which parse the data files.

  AT> Is this implemented anywhere in a comparable form to cdd-dev so that
  AT> I'm able to hae a look at it / build my meta packages with it.  Is
  AT> there any example or whatever which draws this from abstraction to
  AT> a code snipped + data set to look at?

Ok,  I understand my previous   post sounds rather "theoretical". I've
wrote some scripts which I consider quick and  dirty hacks, but if you
like (some of) the idea(s) we can use them as a base.


1) tag definition:


2) tag application:


3) script to generate the menu on the fly (goes in /etc/menu/demudi)


4) script to generate tasksel entries:


5) script to set some default tasksel actions:


   (this has been submitted to the BTS, #275303, and this list was in Cc:)

6) script to sort the packages list by relevance:

   (it's used to distribute the packages over a cd set)

To check out the whole sources read here:


interesting packages are demudi-debtags, demudi-tasksel,  demudi-menu,
demudi-debian-cd, demudi-debpartial-mirror, demudi-cfengine,

  >>and there will be a couple of scripts which will parse it (for example
  AT> "Will be" or "is there" ?

Well,  a mix of both  actually, I've wrote kind  of that, but it's far
from satisfactory.



Reply to: