Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Petter,
On 23.02.2018 11:29, Petter Reinholdtsen wrote:
> [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.
astrometry-data-2mass was in contrib at this time. Gliese is in non-free
since 2004, is also listed as "Depends" in tasks/catalogs and as
"Suggests" in debian/control (just below astrometry-data-2mass).
>> 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.
blends-dev did generate policy conform packages in Stretch by
automatically downgrading everything not in main, and is now creating
packages that violate policy from basically the same source.
> 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.
What is the use case for that?
>> 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.
It does *not* check the package list for _existance_ anymore. It puts
everything into Recommends, independent of being in main, contrib,
non-free or not packaged at all. That is the content of this bug.
BTW, when running "make", it properly shows the missing packages:
```
/usr/share/blends-dev/blend-gen-control -s unstable -S -c -m -i -A) >
debian/control.new && mv debian/control.new debian/control
Hit:1 http://ftp.debian.org/debian testing InRelease
Reading package lists... Done
Missing or avoided packages:
[...]
astrometry-data-2mass
[...]
audela
[...]
gliese
```
It just does not use the list for lowering the dependency.
Best
Ole
Reply to: