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