Re: Using tasksel features (Was: an idea for debian-edu tasks)

[Free Ekanayaka <free@agnula.org>]

|--==> "AT" == Andreas Tille <tillea@rki.de> writes:

  AT> Hello,
  AT> I'd like to point out you to this mail from Joey Hess at debian-edu
  AT> mailing list because it concerns all CDDs.  I'd suggest to continue
  AT> the discussion at debian-custom because it belongs to this list and
  AT> we might CC Joey Hess (and others who might be only subscribed to
  AT> debian-edu but not debian-custom).

  AT> On Fri, 16 Jul 2004, Joey Hess wrote:

  >>We're still having much trouble getting the education-* packages into
  >>testing. The next release of tasksel will have some features that could
  >>let us use it instead of task packages, and avoid these problems.
  >>
  >>Here's how it could work:
  >>
  >>- debian-edu installations install a education-tasks package, or similar.
  >>- This provides a /usr/share/tasksel/debian-edu-tasks.desc, which lists
  >>the debian-edu tasks.
  >>- Also a /usr/lib/tasksel/packages/debian-edu program. That program would
  >>be responsible for outputting a list of packages to install as part of a
  >>task.
  >>- With the above files in place, tasksel would be able to display and
  >>install debian-edu tasks.
  >>- We could also include a /usr/lib/tasksel/tests/debian-edu, which
  >>would be used to tell tasksel which debian-edu tasks to automatically
  >>install, based on /etc/debian-edu/config.
  >>- debian-edu-install would be changed to let tasksel run during
  >>base-config. The debconf priority would prevent tasksel from being
  >>seen, but it would install all the appropriate packages from
  >>debian-edu tasks just as it does for other Debian tasks.
  >>
  >>This would solve the problem of education-* task packages dependencies
  >>keeping them out of testing, since we'd no longer have such packages.
  >>The implementation of /usr/lib/tasksel/packages/debian-edu could just
  >>cat out predetermined lists of packages for a task at first, but if we
  >>later wanted to make it use debtags or something more sophisticated,
  >>we'd have the flexability to do that. Another nice benefit is that we
  >>could make the education-laptop task be automatically installed if the
  >>Debian laptop task was installed (the Debian laptop task will soon be
  >>automatically installed on all laptops).
  >>
  >>The disadvantages are mostly related to not being able to apt-get install
  >>education-whatever. We would need to deal with upgrades in some other
  >>way. Perhaps we would still include education-* packages, but rather
  >>than depending on everything in the task, they could just be installed
  >>as part of it, and be used to add new packages during upgrades.
  >>
  >>Another area of complication is getting the package lists for the CD.
  >>Simply adding the education-* packages to the CD would not do it anymore
  >>(if it ever really did). The new tasksel has a facility to list the set
  >>of packages in a task, and I will probably hook this into debian-cd.

  AT> If you ask me I see no chance in the near future to get rid off the meta
  AT> packages approach because the suggestion of Joey just covers one aspekt
  AT> of the sense of meta packages - the dependencies.  If you have a look at

  AT>    http://people.debian.org/~tille/cdd/ch-technology.en.html#s-metapackages

  AT> I see no clue how to go for the other three points.  On the other hand it
  AT> might be useful to profit also from the enhanced features of tasksel because
  AT> tasksel is the very first interface after new installations.  Is there any
  AT> short intro into the new features of tasksel which might help representing
  AT> every single CDD in an apropriate way?

I  thing Joey's ideas,  though   not exhaustive, are  a good  starting
point. With regards to the three points Andreas is mentioning:

* Menu entries: I feel we should find a way to automatically generate them, 
  rather than hand writing files in task packages. This could be cleanly done
  for example using the debtags categorisation. E.g. if a package is tagged
  with DebianEdu.Physics.Mechanics a proper menu file can be generated.

* Configuration stuff: AFAIK currently both DebianEdu and DeMuDi keep the
  cfengine and configuration script in a separate package (debian-edu-config
  and demudi-base respectively). However this choice can be matter of 
  discussion.  

* Special meta package: I can't see exactly why Joey's proposal is in conflict
  with the <cdd>-common package.. You can still have it even without meta-packages.
  Am I missing something?

Cheers,

Free