[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:
  >>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! ;)
  AT> OK, understand.
  AT> So would you recommend us to proceed like before and switch afterwards
  AT> or join your efforts?

  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
  >>one.
  >>
  >>xmedcon: task::imaging, menu::Med/Imaging/Conversion
  >>garlic:  task::bio,     menu::Med/Bio/Molecular

  AT> Well, I'm sure that this will work if you tag the packages which is definitely
  AT> a good approach but subgrouping also works in the current system if you
  AT> put this entry after "menu::" into the menu files.  That's all I wanted
  AT> to say.

But you may need other package specific info, and then you have to add
more  files and   things  get more   complex. I  feel  it's  not  that
scalable..

  >>Well, ok  we are talking about "little"  things, but this doesn't mean
  >>that we don't have to do things cleanly and beautifully..
  AT> Sure.  I love this.  But currently I would love any *working* solution
  AT> first (to enable me to concentrate I *really* want to do) before making
  AT> the solution beautiful.  But it is good to know that somebody will care
  AT> for the beauty in the mean time. ;-))

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

  >>3) script to generate the menu on the fly (goes in /etc/menu/demudi)
  >>
  >>http://costa.wiggy.net/svn/demudi/demudi-menu/trunk/demudi-menu?op=file&rev=0&sc=0
  AT> Would it be a problem to move this to
  AT>         /usr/share/cdd/#CDDNAME#/menu       ?
  AT> At least this is the place we agreed to.

I've considered it, don't  think I'm a total  anarchist. But AFAIK the
update-menus script  doesn't  look  for   (executable) files  in   the
directory  you  mention. It does     look for  (executable) files   in
/etc/menu.

  >>4) script to generate tasksel entries:
  >>
  >>http://costa.wiggy.net/svn/demudi/demudi-tasksel/trunk/demudi-tasks.desc?op=file&rev=0&sc=0
  AT> Did you found a good place to store tasksel entries.  I'm a little bit unsure
  AT> about this tasksel stuff which is basically the reason why the cdd package
  AT> version 0.3.10 did not hit the mirror yet.

Tasksel entries  are  generated on  the fly basing  on the information
found in the tag database. That means, tasksel executes this script:

/usr/share/tasksel/demudi-tasks.desc

and  the scripts  writes on STD  out the  task definitions in  tasksel
format using the information of the tag definition:

http://costa.wiggy.net/svn/demudi/demudi-debtags/trunk/tagvoc?op=file&rev=0&sc=0

I've  patched  tasksel to  support  executable  .desc,  and there's  a
wishlist item for this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279085

  >>To check out the whole sources read here:
  >>
  >>http://demudi.alioth.debian.org/wiki/DevelopCode

  AT> Sergio, what are you thinking about this?  I leave the decision to proceed
  AT> here or at the "old" cdd package to you.  On top of my personal todo list
  AT> is definitely the GnuMed package and I'll not touch cdd before this package
  AT> is uploaded.

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

  AT> OK, just give us a hint what would be the fastest way to a working solution
  AT> for any CDD who want to take part in the common effort.  Support for your
  AT> "nice" system or support for the "old" system.

Well, I  really  don't   know. I say    that my  current  approach  is
experimental and has drawbacks, but more or less I like the idea.

Cheers,

Free




Reply to: