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

Re: Bug#1018146: correct multiarch for blends stuff?

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

Reply to: