Quoting Ole Streicher (2022-08-27 17:57:21) > Petter Reinholdtsen <pere@hungry.com> writes: > > [Ole Streicher] > >> I think this contradicts Debian Policy 2.2.1: > > > > Which relation did you have in mind that lead you to this idea? > > > > I thought we were discussing metapackages depending on packages in main, > > in unstable, which fail to build on one or more architectures. > > I think the interpretation was that for a given Debian release, all > (primary) Recommends must be resolved in main. That's why we usually > wait for the last moment to upload the final version of a Blends > metapackage, and that's why the build process explicitly takes the > "testing" (i.e. proposed next stable) version and not the "unstable" one > to generate the Recommends. And since the current "testing" package list > is not locally available during build, the Blends package needs to create > them before upload (resulting in a complicated build procedure, using > a template for d/control). > > If our policy should be interpreted as "package can be somewhere in > main, not necessarily in the Debian release", then we can greatly > simplify the way Blends are handled, by computing the Recommends list at > build time. Then, one would in principle just need a no-change reupload > (or a BinNMU) after the soft freeze. > > While I doubt that the sloppy interpretation is correct, I would also > like to have this clarified (and then implemented) in the lazy way. As I recall, what gets rejected is a _dependency_ for a package _does_ exist in main but is missing from some architectures. Would probably be best to get some solid insight from the release team. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature