[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

It just does not use the list for lowering the dependency.



Reply to: