Re: cleaning up our task packages
This sounds good to me. Also, why should the user ever see a task like
devel-common, shouldn't this be essentially depended on by all the dev
tasks? And Debug should be pulled in for any languages for which it
includes debugging tools. In at lease some cases (SGML at least) it would
seem to me to make sense to merge the dev and the use tasks. Speaking for
myself, if am being lazy and want to 'do some Tcltk tasks' I want both the
use and development packages by default.
Britton
On Thu, 7 Dec 2000, Joey Hess wrote:
> [ I'm dropping the -devel cc in the hope of having a useful discussion
> instead of 10 non-useful offtopic discussions. Blah. ]
>
> Chris Waters wrote:
> > Ok, here's a slightly better proposal: why not simply handle the task-
> > package namespace the same way we do virtual packages and menu
> > entries. That way the actual text to go into policy almost writes
> > itself, and the only challenging part of the job would be deciding on
> > the initial tasks to seed the official list.
>
> The problem I have with this is illistrated pretty clearly by most of
> this thread.
>
> We introduced the concept of task packages less than a year ago. At that
> point everyone who was contributing had a basic idea of the purpose of
> task packages and how they were meant to be used, and what was
> appropriate for task packages.
>
> Fast forward 8 months to the present, and I'm seeing a huge number of
> people who don't have the slightest clue about task packages. Did they
> forget so soon? Did they not pay attention last winter? I don't know..
>
> But if we just make it policy that task-foo has to be approved by
> debian-devel before it is allowed into debian, I have fears that in
> another 8 months everyone is again going to have forgotten what task
> packages are for, and this mailing list may be unable to
> approve/disapprove packages with any consistency.
>
> All right, call me pessamistic, but policy is supposed to be there to
> help us remember why we do things the way we do, so even if people
> forget, the document is there for those who remember to cluebat others
> with. :-) That's why I think we need at least a clear statement of what
> task packages are for, what is and what is not allowable, put into
> policy.
>
> I don't object to requiring new task packages to be approved by the
> debian-devel list like virtual packages, but the list will need something
> on which to base its decisions.
>
> So how's this:
>
> Task Packages
> -------------
>
> Any package whose name begins with `task-' is known as a "task
> package". Task packages are intended to help a new user install a set of
> packages which they need to perform a specific task. Since a list of all
> task packages is presented during new Debian installations, task packages
> should only exist for common tasks for which a user may plausibly want to
> use a newly installed Debian system.
>
> Before a new task package is added to Debian, the new package must
> be discussed on the debian-devel mailing list to ensure that it meets
> these guidelines. The current list of approved task packages follows:
>
> ...
>
> (If we accepted this, then we'd use its procedure to discuss each of the
> existing task packages, add those that were accepted to the list, and
> file bugs on the rest.)
>
> --
> see shy jo
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: