Re: Using tasksel features (Was: an idea for debian-edu tasks)
|--==> "AT" == Andreas Tille <firstname.lastname@example.org> writes:
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
>>- 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> 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
* 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?