Re: 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
[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
Re: Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Petter, On Fri, Feb 23, 2018 at 10:56:08AM +0100, Petter Reinholdtsen wrote: > > 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. Petter, if I might refresh your mind ;-): blends-dev has pulled Packages.gz as per /etc/blends/sources.list.* (by default /etc/blends/sources.list.testing since this will be our target release). If you provide a different sources.list file with -s option or if you change your local configuration by adding other resources, than you can tweak this behaviour. Blends-dev has checked, whether a package exists there (by default testing/main). Everything that did not existed there (may it be in contrib/non-free/somewhere-else) was put to Suggests. This is how it worked and how it should work to create policy conform packages. > 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). Kind regards Andreas. -- http://fam-tille.de
Re: 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
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
