Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Petter,
On 23.02.2018 10:56, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> This violates the policy in the generated blends tasks packages;
>> therefore the severity.
>>
>> IMO this is a regression; it worked some time ago, right?
>
> As far as I know, this has never behaved differently. I am not aware
> of blends-dev every looking at main/contrib status, only if the
> package exists.
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:
https://sources.debian.org/src/debian-astro/1.0/tasks/catalogs/#L10
https://sources.debian.org/src/debian-astro/1.0/debian/control/#L69
("Depends" was renamed to "Recommends" in the tasks after Stretch).
The idea here is that when typing "make", the latest package list (of
main) is downloaded, and all packages from the tasks are compared to it.
When a "Recommended" package is not in the tasks list, it gets
downgraded to "Suggests" in d/control. That was the processing at that time.
> In my view, it is the responsibility of the people writing the tasks
> to decide if a package in contrib should use recommends or suggest,
> not the blends build system. I would thus classify this as a
> wishlist issue, and recommend against changing the current default,
> as changing this would make it impossible to use blends-dev to create
> a task where the developer want to recommend a package in contrib or
> non-free.
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 [...]
> In short, I do not agree that this 'violates the policy' to do what
> the task writer intends. It might be useful to emit a warning if the
> build system detect a recommend from main to contrib or non-free, but
> it should not prohibit task writers from creating such tasks.
And this is only a side problem (I should have brought them in opposite
order). This also affects packages that are not at all (yet) in Debian.
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.
Best
Ole
Reply to: