Table of Contents
If the source for the Blends package is maintained in Blends VCS every Debian
developer and each member of the Alioth team "Debian Pure Blends" have commit
permission to the package source. Once you checked it out you find the single
tasks files inside the tasks/ directory. Fine one or
more tasks you want to put the package into and add the line.
Depends: package
or
Suggests: package
As explained in Section 8.2, “Tasks files controlling web sentinel content” you can specify several metadata in addition to the pure dependency which is used for the metapackage creation to enrich the web sentinel with extra information about the package. Usually the information is obtained from the Debian package information. However, as it was explained it makes perfectly sense to even specify packages which are not yet included into official Debian. The information is taken from the Ultimate Debian Database (UDD)
Since the Blend team also has injected the packages in the NEW queue as well as the information about packages in VCS of Blends it is sufficient even for packages which are not yet ready to only specify the name. In this case it is detected that the package is work in progress and the tasks page of the web sentinel will put the package into the appropriate section.
The big advantage of injecting a package into the relevant task is that visitory of the tasks page will be informed about the work in progress and can follow for instance enhancements of the desciprion or the migration of the package into the Debian pool without any further action. Since this is very convenient you want to add your package to the tasks immediately after you injected the first rough packaging into VCS.
A tasks file is in principle a debian/control file
snippet. In these files you are specifying binary
packages. It is a common error to inject source package names which is
wrong if the resulting package is different.
User oriented metapackages should depend from user oriented applications. You should avoid specifying a package containing a dynamic library. If the package you want to add is a library you should rather add the development package (containing the static library and header files) to the according development task if this exists.
Yes. Please discuss this with the Blends team on their mailing list but in principle it is totally OK to add a new task to a Blend.
People frequently claim that they prefer a simple list in a Wiki to list the interesting packages for their work. This is a waste of time since:
An entry in a tasks file makes the same effort (measured in time and numbers of keys pressed).
You need to manually add the metadata (like Homepage, description etc.)
Metadata are updated automatically in the web sentinel tasks - Wikis are usually aging (despite being a Wiki)
You get a lot of metadata for free:
Translated descriptions
Version + release
Popularity contest results
Debtags
Screenshot
You will have a hard time to provide all this on a Wiki and keep it up to date
Automatic information whether Debian is lagging begind upstream
If a package was introduced into Debian after the work in VCS was successfully finished the web sentinel is updated automatically without any extra work.
If you want to create metapackages for user installation or to easily feed some live DVD you need to create tasks files anyway and thus you are not duplicating any work.
In general I'd like to quote Enrico Zini about the relation of DebTags and Blends tasks: "Both efforts are orthogonal to each other and a well designed task should cover a specific workfield which is not necessarily given due to the fact that a package belongs to a certain (DebTag) category."
Moreover if you exclusively rely on the DebTags you are ignoring additional options the Blends framework is providing. For instance the Biology task of Debian Med contains several sections about packages which are not yet available in the Debian package pool. This includes:
Packages inside the new queue
Packages the team is working on in VCS
Unofficial packages at some other places
Information about not yet packaged software that might be of certain interest
This turns out as a very useful todo list to grab work items from as well as information to prevent duplication of work. (Yes ITP bugs do not always work out that reliably.)
The Blends framework works quite nicely automatically if packages "upgrade" from one section to the other which means if you specify a package which has only some packaging in VCS it is sufficient to simply add a dependency to the tasks file and it shows up here (to stick to our example above). So all relevant information is just taken from VCS and if you for instance change the description in your packaging the tasks page will be updated automatically (after some cron job delay).
Once the package might be uploaded the first time it migrates to the section named "Debian packages in New queue (hopefully available soon)" (which is only available if there are such packages) and finally once ftpmaster might have accepted the package it shows up in the tasks ... even not yet DebTagged. You have another delay until the DebTag information is propagated properly and thus relying on DebTags in this whole process does not work.