Re: Bug#1018146: correct multiarch for blends stuff?
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.
Cheers
Ole
Reply to: