# FAQ

## How can I add a dependency?

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

## What additional information should be provided?

As explained in edittasksfiles 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.

## Should I add binary or source packages?

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.

## Should I add a library package to a user task?

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.

## Can I create a new task if the existing ones do not fit?

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.

## Why not simply use a Wiki?

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:

1. An entry in a tasks file makes the same effort (measured in time and numbers of keys pressed).

2. You need to manually add the metadata (like Homepage, description etc.)

3. Metadata are updated automatically in the web sentinel tasks - Wikis are usually aging (despite being a Wiki)

4. 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

5. Automatic information whether Debian is lagging begind upstream

6. 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.

7. 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.

## Why not simply using DebTags?

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:

1. Packages inside the new queue

2. Packages the team is working on in VCS

3. Unofficial packages at some other places

4. 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.