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

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


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

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.

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


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

Kind regards


Reply to: