Processed: Re: Bug#891188: blends-dev: created d/control recommends packages not in main
Processing control commands: > severity -1 important Bug #891188 [blends-dev] blends-dev: created d/control recommends packages not in main Severity set to 'important' from 'serious' -- 891188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891188 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#891188: blends-dev: created d/control recommends packages not in main
Control: severity -1 important To work around the described problem it is sufficient to set GENCONTROL_DEPENDS = false (or simply not to set it inside Makefile at all == stick to the current default) Reducing the severity enables us to keep on using blends-dev as is while we are discussing the proper approach to replace it by a rewrite. On Thu, Mar 15, 2018 at 04:55:24PM +0100, Ole Streicher wrote: > Feel free to lower the severity. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole,
On Fri, Mar 16, 2018 at 01:51:25PM +0100, Ole Streicher wrote:
> On 15.03.2018 19:41, Andreas Tille wrote:
> > I've commited a fix to Git which for me creates now sensible Debian
> > Astro metapackages.
>
> For me, it actually upgrades the "Recommends" with to "Depends". For
> example, the "education" task (shortened):
>
> ```
> Task: Education
> Install: true
> Description: Educational astronomy applications [...]
>
> Recommends: celestia-gnome, gpredict, kstars
> Suggests: sunclock, xtide
> ```
>
> becomes in d/control:
>
> ```
> Package: astro-education
> Section: metapackages
> Architecture: all
> Depends: ${misc:Depends},
> astro-tasks (= ${source:Version}),
> gpredict,
> kstars
> Recommends: celestia-gnome
> Suggests: sunclock,
> xtide
> Description: Educational astronomy applications [...]
> ```
This does not sound good. :-(
> celestia-gnome is a package that does not exist in unstable.
> GENCONTROL_DEPENDS is set to TRUE.
My short term recommendation would be to set this to FALSE.
> In the moment, I would tend to rewrite blend-gen-control from scratch,
> using Python 3 and the standard Debian Python packages (debian.deb822,
> apt) in a modular fashion. This would make the script much more
> maintainable (given the knowledge of Python is a bit better than Perl),
> and could also lead to create a "debian.blends" Python package that
> could be re-used for the Web pages.
I can only repeat: Blends-dev *was* rewritten and creates correct
results:
https://salsa.debian.org/blends-team/blends-gsoc
I repeat again: This creates *architecture* dependent metapackages (I
explained here why only this makes sense). I'm all for switching to
Python3 but a complete rewrite should not be necessary. There are some
glithes in the code (for instance line breaking in the auto generated
part of d/changelog) and it definitely needs testing.
> Any thoughts on that? I'd volunteer here.
I *really* appreciate your effort but may be 80% of the work is just
done and you try blends-gsoc first. As we all know the last 20% is
the harder part - but I urgently vote for using UDD as base for
anything we use. May me using the public UDD mirror can help to not
force everybody who wants to run blends-dev having a local clone.
> Best regards
Thanks a lot for pushing things
Andreas.
--
http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Andreas,
On 15.03.2018 19:41, Andreas Tille wrote:
> I've commited a fix to Git which for me creates now sensible Debian
> Astro metapackages.
For me, it actually upgrades the "Recommends" with to "Depends". For
example, the "education" task (shortened):
```
Task: Education
Install: true
Description: Educational astronomy applications [...]
Recommends: celestia-gnome, gpredict, kstars
Suggests: sunclock, xtide
```
becomes in d/control:
```
Package: astro-education
Section: metapackages
Architecture: all
Depends: ${misc:Depends},
astro-tasks (= ${source:Version}),
gpredict,
kstars
Recommends: celestia-gnome
Suggests: sunclock,
xtide
Description: Educational astronomy applications [...]
```
celestia-gnome is a package that does not exist in unstable.
GENCONTROL_DEPENDS is set to TRUE.
In the moment, I would tend to rewrite blend-gen-control from scratch,
using Python 3 and the standard Debian Python packages (debian.deb822,
apt) in a modular fashion. This would make the script much more
maintainable (given the knowledge of Python is a bit better than Perl),
and could also lead to create a "debian.blends" Python package that
could be re-used for the Web pages.
Any thoughts on that? I'd volunteer here.
Best regards
Ole
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Wolfgang, thanks a lot for checking. On Fri, Mar 16, 2018 at 12:07:28PM +0100, Wolfgang Schweer wrote: > On Thu, Mar 15, 2018 at 07:41:30PM +0100, Andreas Tille wrote: > > I've commited a fix to Git which for me creates now sensible Debian > > Astro metapackages. > > I've checked how this fix would concern Debian Edu: > > (1) The Debian Edu Makefile has to be adjusted: > s/GENCONTROL_DEPENDS = true/#GENCONTROL_DEPENDS = true/ > > (2) Packages not available (any more) in testing are then correctly > demoted from Recommends to Suggests due to the $missinglist fix. (It > seems those have been wrongly kept as Recommends since the August > 2017 changes.) > > (3) The strong depends on gosa-plugin-netgroups needed due to Bug > #793667¹ (IMO cause for 'GENCONTROL_DEPENDS = true') are a non issue > since ages. I figure in a similar case adding information to the > Debian Edu upgrade chapter seems to be sufficient (if a smarter > solution isn't easy). I would summarise your check with: "Works for Debian Edu" Kind regards Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
On Thu, Mar 15, 2018 at 07:41:30PM +0100, Andreas Tille wrote: > I've commited a fix to Git which for me creates now sensible Debian > Astro metapackages. I've checked how this fix would concern Debian Edu: (1) The Debian Edu Makefile has to be adjusted: s/GENCONTROL_DEPENDS = true/#GENCONTROL_DEPENDS = true/ (2) Packages not available (any more) in testing are then correctly demoted from Recommends to Suggests due to the $missinglist fix. (It seems those have been wrongly kept as Recommends since the August 2017 changes.) (3) The strong depends on gosa-plugin-netgroups needed due to Bug #793667¹ (IMO cause for 'GENCONTROL_DEPENDS = true') are a non issue since ages. I figure in a similar case adding information to the Debian Edu upgrade chapter seems to be sufficient (if a smarter solution isn't easy). Wolfgang ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793667 signature.asc Description: PGP signature
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole, On Thu, Mar 15, 2018 at 05:14:36PM +0100, Andreas Tille wrote: > > Feel free to lower the severity. > > I think there is no need to since I found the part of the code where the > issue occures. If I would only understand Perl a bit better I would be > ready with a fix. :-( I've commited a fix to Git which for me creates now sensible Debian Astro metapackages. I'd love some review / enhancement of my beginners Perl code before uploading. Kind regards Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole,
On Thu, Mar 15, 2018 at 04:55:24PM +0100, Ole Streicher wrote:
> >
> >GENCONTROL_DEPENDS = true
> >
>
> Feel free to lower the severity.
I think there is no need to since I found the part of the code where the
issue occures. If I would only understand Perl a bit better I would be
ready with a fix. :-(
> However, that was a change of the
> default behaviour that we discussed a year ago: we wanted to remove the
> translation
>
> "Depends:" (tasks) -> "Recommends:" (d/control)
> "Recommends:" (tasks) -> "Suggests:" (d/control)
>
> in favour of a direct copy.
Its true that we agreed upon this and the code **seemed** to do this.
However, if there is no Depends -> Recommends the check whether the
missings need to be removed is simply not done.
> I am wondering why debian-astro is the only
> blend which finally used this, and I think we wanted to convert all.
I have not seen any reason to switch any behaviour since there are no
strict Depends in Debian Med. Thus I just substituted
s/Depends/Recommends/ inside the watch file "to be prepared" and be more
expclicit what we mean. But I had no reason to force any switch. Most
probably all other Blends did the same as I in Debian Med and thus you
were simply the only one who was stumbling upon this issue.
> > But I do not want to play severity ping-pong and will have a look
> > why GENCONTROL_DEPENDS is obviously breaking this.
>
> That is probably the code that was introduced for this purpose (August
> 2017).
It is
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 267) my $pkglist;
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 268) my $missinglist;
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 269) if (defined $taskinfo{$task}{Depends})
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 270) {
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 271) ($pkglist, $missinglist) =
process_pkglist(join(",",@{$taskinfo{$task}{Depends}}));
36791f91 cdd/devtools/cdd-gen-control (Andreas Tille 2007-08-27
17:48:49 + 272) }
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 273)
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 274) my (@depends, @recommends, @suggests);
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 275)
0fc23d84 devtools/blend-gen-control(Mike Gabriel2017-08-21
13:51:30 -0400 276) push @depends, $tasksname.' (=
${source:Version})';
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 277) push @depends, '${misc:Depends}';
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 278) push @depends, @{$pkglist}
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 279) if defined $pkglist;
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 280)
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 281) push @recommends,
@{$taskinfo{$task}{Recommends}}
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 282) if defined $taskinfo{$task}{Recommends};
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 283)
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 284) push @suggests, @{$missinglist}
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 285) if defined $missinglist;
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 286) push @suggests,
@{$taskinfo{$task}{Suggests}}
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 287) if defined $taskinfo{$task}{Suggests};
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 288)
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 289) my @depends_sorted = sort_uniq(\%seenlist,
@depends);
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 290) my @recommends_sorted =
sort_uniq(\%seenlist, @recommends);
a452586c devtools/blend-gen-control(Mike Gabriel2017-08-11
23:39:29 -0400 291) my @suggests_sorted = sort_uniq(\%seenlist,
@suggests);
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Andreas, On 15.03.2018 16:16, Andreas Tille wrote: > I tend to set the issue from serious to important since I now found out > why the problem seems to occure only in the case of Debian Astro (or may > be any other Blend that is using > >GENCONTROL_DEPENDS = true > Feel free to lower the severity. However, that was a change of the default behaviour that we discussed a year ago: we wanted to remove the translation "Depends:" (tasks) -> "Recommends:" (d/control) "Recommends:" (tasks) -> "Suggests:" (d/control) in favour of a direct copy. I am wondering why debian-astro is the only blend which finally used this, and I think we wanted to convert all. > But I do not want to play severity ping-pong and will have a look > why GENCONTROL_DEPENDS is obviously breaking this. That is probably the code that was introduced for this purpose (August 2017). Best Ole
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole, On Fri, Feb 23, 2018 at 10:43:01AM +0100, Ole Streicher wrote: > Package: blends-dev > Version: 0.6.100 > Severity: serious I tend to set the issue from serious to important since I now found out why the problem seems to occure only in the case of Debian Astro (or may be any other Blend that is using GENCONTROL_DEPENDS = true I've found out that with the following change diff --git a/Makefile b/Makefile index 7734c93..3be1b00 100755 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ #!/usr/bin/make -f BLENDMAKEFILE=/usr/share/blends-dev/Makefile -GENCONTROL_DEPENDS = true +# GENCONTROL_DEPENDS = true CheckBLENDMakefile := $(shell if [ -e $(BLENDMAKEFILE) ] ; then echo 1 ; else echo 0 ; fi) ifeq ($(CheckBLENDMakefile),1) the intended behaviour to have packages in contrib/non-free will be Suggests only. But I do not want to play severity ping-pong and will have a look why GENCONTROL_DEPENDS is obviously breaking this. Kind regards Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole, On Fri, Feb 23, 2018 at 01:32:17PM +0100, Ole Streicher wrote: > > No. As you can see from my last mail, the list of missing or avoided > packages seems to be generated properly. It is just not used to lower > the dependencies. Interestingly enough I can reproduce the issue for Debian Astro but in Debian Med and Debian Science the packages from contrib/non-free and up in Suggests. So I can not reproduce the issue on other examples which is really strange. Kind regards Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
On 23.02.2018 14:00, Petter Reinholdtsen wrote: > If the sources.list file do not list contrib and non-free, as any > policy compliant task setup should, then no package from contrib and > non-free will be listed as recommended in the resulting task > package. s/will/shall/ That is the problem. > I understand Ole to claim that blends-dev previously would somehow > filter packages from contrib and non-free even if they are listed as > present using the sources.list entries. This do not match my > understanding of how blends-dev ever worked. No; I wrote: | when I run "make" on a blend's package, it puts all that is in | "Recommends" in the tasks package into "Recommends" of d/control, | independent of the status of the package. and I took as first example a package that is not in main (but in contrib), and a second example a package that is neither in main nor in contrib or non-free. > I believe that if someone need or want to create a unofficial task > with some packages in contrib, non-free or some unofficial APT > source, they should be allowed to do so by listing these entries in > their sources.list files. And those of us uploading tasks to > debian/main should not list anything byt debian/main in our > sources.list files. This is not what the bug is about. Cheers Ole
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole, On Fri, Feb 23, 2018 at 01:32:17PM +0100, Ole Streicher wrote: > could you Cc your mails to the bug? Ups, bounced ... > On 23.02.2018 13:23, Andreas Tille wrote: > > Did you somehow changed /etc/blends/sources.list or are you > > pointing to some different location with -s option? > > No. As you can see from my last mail, the list of missing or avoided > packages seems to be generated properly. It is just not used to lower > the dependencies. This would mean the behaviour has changed. :-( I admit I can not check since I'll travel the next four days and will be back to normal at 28.2. :-( May be some git bisecting (for this I use a symlink of /usr/share/blends-dev to my Git repository has proven quite usefull) will enable to find the problematic piece of code. The chancge from Depends to Recommends might seem suspicious, thought. Sorry for not beeing able to help more Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole, On Fri, Feb 23, 2018 at 10:43:01AM +0100, Ole Streicher wrote: > > when I run "make" on a blend's package, it puts all that is in > "Recommends" in the tasks package into "Recommends" of d/control, > independent of the status of the package. > > Examples, from debian-astro > https://salsa.debian.org/debian-astro-team/debian-astro Did you somehow changed /etc/blends/sources.list or are you pointing to some different location with -s option? Kind regards Andreas. -- http://fam-tille.de
Bug#891188: blends-dev: created d/control recommends packages not in main
[Andreas Tille] >> 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. > > No. Recommends need to reside in main (per policy). I believe I understand what both you and Ola mean, and your description matches my understanding of how blends-dev work. It does not match how I understand Ole. If someone create a task with contrib and non-free in the associated sources.list, any packages in contrib and non-free will be detected as present and allowed to be listed as recommends. If the sources.list file do not list contrib and non-free, as any policy compliant task setup should, then no package from contrib and non-free will be listed as recommended in the resulting task package. I understand Ole to claim that blends-dev previously would somehow filter packages from contrib and non-free even if they are listed as present using the sources.list entries. This do not match my understanding of how blends-dev ever worked. I believe that if someone need or want to create a unofficial task with some packages in contrib, non-free or some unofficial APT source, they should be allowed to do so by listing these entries in their sources.list files. And those of us uploading tasks to debian/main should not list anything byt debian/main in our sources.list files. -- Happy hacking Petter Reinholdtsen
Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Andreas, could you Cc your mails to the bug? On 23.02.2018 13:23, Andreas Tille wrote: > Did you somehow changed /etc/blends/sources.list or are you > pointing to some different location with -s option? No. As you can see from my last mail, the list of missing or avoided packages seems to be generated properly. It is just not used to lower the dependencies. Best Ole
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
Bug#891188: blends-dev: created d/control recommends packages not in main
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
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
Bug#891188: blends-dev: created d/control recommends packages not in main
[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. 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. 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. -- Happy hacking Petter Reinholdtsen
Bug#891188: blends-dev: created d/control recommends packages not in main
Package: blends-dev
Version: 0.6.100
Severity: serious
Hi,
when I run "make" on a blend's package, it puts all that is in
"Recommends" in the tasks package into "Recommends" of d/control,
independent of the status of the package.
Examples, from debian-astro
https://salsa.debian.org/debian-astro-team/debian-astro
tasks/catalogs:
```
Task: Catalogs
Install: false
Description: Astronomy catalogs
This metapackage will install [...]
Recommends: stardata-common, gliese, yale
Recommends: astrometry-data-tycho2, astrometry-data-2mass
```
Here, astrometry-data-2mass is not in main, but in contrib; therefore
the dependency should be lowered to "Suggests". However, in d/control:
```
Package: astro-catalogs
[...]
Recommends: astrometry-data-2mass,
astrometry-data-tycho2,
gliese,
stardata-common,
yale
Description: [...]
```
The same happens with packages that are not uploaded yet, f.e. the
package "audela" in tasks/telescopecontrol ("Recommends", with a WNPP
entry) is still not packaged, but is "Recommends" in astro-telescopecontrol.
This violates the policy in the generated blends tasks packages;
therefore the severity.
IMO this is a regression; it worked some time ago, right?
Cheers
Ole
