[Not sure whether we should keep the long To: - list, I'd suggest
continuing on debian-devel but keep it for the moment.]
On Thu, Feb 17, 2011 at 07:20:30PM -0400, Joey Hess wrote:
> A long time ago, tasksel installed task packages, which were regular
> metapackages. This was dropped because the task packages had to Depend
> on many packages, which made the installed system brittle, and made
> testing propigation a problem. Now that Recommends are installed by
> default, I'm revisiting the idea of using task packages. It solves
> many issues and inconsistencies with tasksel vs the rest of Debian.
If I understand the consequences of the statement correctly I welcome
this step very much.
> ### blends
>
> I think there is interest in getting some blends displayed in Taskel?
Yes, definitely!
> It's mostly orthagonal to this proposal, but this would help with
> giving you full control over what your tasks do. I do feel that blends
> need to be listed below the other tasks in tasksel, and probably with
> a divider between them.
This would be an acceptable approach.
> Also, we have been careful to only have ten
> tasks, to avoid overloading the user; and there is a limit to the length
> of the list before it begins scrolling, so the d-i team would have to
> look at the UI before adding Blends to the interface.
The requirement for a limited set of tasks to provide a good overview is
reasonable but has two flavours: On one hand it restricts the number of
Blends we can include into the list and on the other hand it might have
an influence on the number of "tasks"[1] we are maintaining inside each
Blend which exceeds 10 drastically at least for three Blends (the most
active ones).
>From my perspective the only reasonable solution for this "reduced
number of list entries" requirement is to close bug #273797 and have a
hierarchical task selection where you first select the Blend and than
select a set of "tasks"[1] inside the Blend.
[1]
Remark: I have the feeling that in the Blends context we are using the
term "task" in some different manner. While it was probably influenced
by tasksel (and invented by the Debian Edu developers) it drifted a bit
away somehow. I have the feeling that we should find a proper
definition what we mean when talking about Blends.
> ## Implementation Option A
>
> Put everything in the task package.
>
> ...
>
> ## Implementation Option B
>
> Keep Test-*, Enhances, Relevance, and Section in the debian-tasks.desc
> file; move the other fields to the task packages.
I'm afraid I do not fully understand the difference / consequences of these
two options. Can you provide some short examples?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-i18n-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110218134908.gh9...@an3as.eu
