Bug#891188: blends-dev: created d/control recommends packages not in main

[Petter Reinholdtsen <pere@hungry.com>]

Hi Ole,

[Ole Streicher]
> It did. astro-catalogs 1.0 (included in Stretch) has "Suggests:
> astrometry-data-2mass" in the package and "Depends:
> astrometry-data-2mass" in the tasks page:

But why did it?  Was it because astrometry-data-2mass was in contrib or
non-free while astro-catalogs was in main, or because
astrometry-data-2mass was simply missing from the checked package lists
when the task was created?  I believe the latter, as I have not seen
blends-dev checking main/contrib/non-free status.

> Violates Debian policy 2.2.1:
>
> | In addition, the packages in main
> |  * must not require or recommend a package outside of main for
> |    compilation or execution [...]

This only documents that it is _possible_ to use blends-dev to create
non-policy compliant tasks, which is a given.  This in it self do not
make blends-dev in conflict with policy.  It is the responsibility of
the task writers to ensure policy compliance regarding
main->contrib/non-free relations, not blends-dev.  I see it as similar
to the fact that emacs can be used to create non-policy compilant
debian/control files, which do not make emacs break policy.

If you do not want blends-dev to create tasks with recommends from main
to contrib, I recomment to not list packages in contrib as recommends in
the tasks.  There is no use nor sense in in blaiming blends-dev.

My conclusion is that it is wise to keep blends-dev in a state where it
is _possible_ to create policy breaking tasks, and leave it to the task
author to avoid it.

> Having this processed is the basic idea of a separate "make" task for
> the blends. If there was no comparison to the actual package list, one
> could generate d/control directly in d/rules.

The blends-dev scripts have always checked package lists for
_existance_.  As far as I know, it have not checked anything more.
--
Happy hacking
Petter Reinholdtsen