Hi,

python-mako not being Multi-Arch:foreign is currently blocking 208
source packages from not being able to satisfy their crossbuild
dependencies: https://mister-muffin.de/p/Ztuz.html

The fix is trivial and involves just adding the Multi-Arch:foreign
header to the python-mako package stanza in debian/control.

Please add it if there are no technical reasons not to do so.

cheers, josch

Control: retitle -1 please make python-mako multiarch aware

Adding M-A:foreign is wrong. Suppose you are trying to satisfy
python-mako:i386 on a system that is natively amd64. Then python-mako
would satisfy this dependency and use python-markupsafe:amd64 in its
installation set. However when importing modules in an embedded i386
python interpreter an ImportError would be raised, because
python-markupsafe is unavailable. Thus python-mako exposes the
architecture awareness of python-markupsafe and cannot become
M-A:foreign.

It is not obvious how to solve this problem and it is not obvious
whether python-mako needs to be updated to solve it. In essence, this is
the famous "multiarch interpreter" problem at
https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges#Interpreter_issue.

A feasibly workaround to apply now would be to switch python-mako to
arch:any M-A:same.

Helmut

Hi,

alternatively, python-mako could also demote its dependency on
python-markupsafe to a recommends. python-markupsafe seems to only be used in
mako/filters.py and there seems to be a fallback to pure Python in case
python-markupsafe is not available. Thus python-markupsafe is not a strict
dependency.

Since python-make would then not strictly depend on python-markupsafe anymore,
it could become m-a:foreign.

cheers, josch

Hi all,

#875650 looks like a duplicate of #769380, and according to #769380 back
in 2014 josch and helmut seem to have concluded that the better solution
was to either change the package to "Architecture: any" and "M-A: same",
or demote the dependency on python-markupsafe.

So I think that the bugs should be merged, and 3 years later than the
original submission, I think that it's time to solve this issue unless
there's a good reason to not change it in this way, because it affects
hundreds of packages for cross-compilation.

Piotr, what do you think about this?

Since the package is actively maintained and you uploaded a version very
recently, I am not sure if it makes much sense to offer to NMU, but
nevertheless if we can help in some way, please tell.


Cheers.

They kinda are duplicates, but unless the markupsafe dependency is
demoted, the advice from #875650 to add m-a:foreign is simply wrong.
Since #769380 contains all the deatils, I am simply closing the newer
bug.

It is true that this bug theoretically affects a lot of packages (318).
The vast majority of these (258) go through gobject-introspection
though and will fail to cross build even if this bug is fixed. From what
I understand now, gobject-introspection looks pretty much unfixable. So
realistically, this bug affects 60 packages.
There are multiple ways to fix and nobody knows which one is better. The
first question to answer is whether it would be reasonable to demote the
dependency on markupsafe to recommends. Having an answer on that
question from someone of the DPMT would be very helpful.

Barring that, we're still talking with Guillem whether dpkg could allow
:native annotations on Arch:all packages (which dose does allow). In
case that moves forward, we might be able to cancel this bug.

If all else fails, I see no way around turning it Arch:any at some
point. What we need here is an answer to the demotion question to move
on.

Helmut

Otherwise, I have to deal with python3-mako:i386 not found.

Either way, I'd have preferred you to merge #875650 with #769380, not just
close it.

Well, hopefully this doesn't take another three years. :-)

Quoting Hugh McMaster (2017-10-23 14:11:55)
a special meaning. And if certain conditions are not met, you would also not
add a Depends:foo because it would be wrong. The same goes for Multiarch
markings. Sure, we could make everything in the archive M-A:foreign and as far
as dependency satisfaction goes we would not have any problems anymore because
everything would be satisfied. But then problems would arise once the contents
of a package are actually used by executing them for example. So we can only
mark those packages M-A:foreign that meet certain criteria. For M-A:foreign
this means that the package must not expose an architecture specific interface.
What constitutes such an interface can sometimes be very subtle but in this
case the situation is clear and it was already explained by Helmut in an
earlier Email:

On Fri, 21 Nov 2014 10:41:03 +0100 Helmut Grohne <helmut@subdivi.de> wrote:
 | Adding M-A:foreign is wrong. Suppose you are trying to satisfy
 | python-mako:i386 on a system that is natively amd64. Then python-mako
 | would satisfy this dependency and use python-markupsafe:amd64 in its
 | installation set. However when importing modules in an embedded i386
 | python interpreter an ImportError would be raised, because
 | python-markupsafe is unavailable. Thus python-mako exposes the
 | architecture awareness of python-markupsafe and cannot become
 | M-A:foreign.

Thanks!

cheers, josch

Hi,

2017-10-22 20:07 Helmut Grohne:

So, Piotr, do you think that any of the options is preferable?

If there's no reply I'd like to upload an NMU with a fix for this
problem.

I think that changing the package to "Architecture: any" and "M-A: same"
is safer than dropping a dependency to recommends.  It's not ideal, but
in the end is just causes a small overhead, and changing dependencies
can even break reverse-depends and introduce bugs difficult to detect.


Cheers.

please point me to the policy if it's already known what's the right
approach

Hi Piotr,

2017-12-04 23:16 GMT+01:00 Piotr Ożarowski <piotr@debian.org>:

It's not documented in Policy yet.  The best source of information is:
https://wiki.debian.org/Multiarch

Although probably Ubuntu is best/more accurate/more complete:
https://wiki.ubuntu.com/MultiarchSpec

Abut this package, since the package could be marked "foreign" (as in
"package from foreign arch satisfies dependency") if it was only for
its contents (because it's an arch:all, the same in all arches), but
since it exposes arch-independent behaviour throught dependencies
(i.e. needs to load arch-dependent modules for markupsafe), it cannot
be marked in that way, which is the most beneficial and the original
suggestion.  It has to be marked as "give me the version for the same
architecture that the package to be built that depends on this one".

Despite having binaries in /usr/bin/ and libraries shipped in /usr/lib
but not /<triplet>/ (see next url), since they are byte-for-byte the
same across architectures, it should be covered by the same provisions
as if the files were in /usr/include (but not inside subdir
/<triplet>/), /usr/share, etc. -- at least that's how I interpret it.

https://packages.debian.org/sid/all/python-mako/filelist


Regards.

Dear,

Did you receive the message i sent to you?

Regards,
Peter Joe

Dear,

Did you receive the message i sent to you?

Regards,
Peter Joe

Are there any new developments/insights after 5 years?
It would be great if this bug could be resolved.

be M-A:foreign (as it depends on python3-markupsafe and technically
exposes its architecture). However, python3-mako could be split into a
package containing the module and a package containing the script. The
package containing the script could plausibly become M-A:foreign. The
module could plausibly become M-A:same (i.e. "M-A interpreter
workaround"). We've done such a split for similar situations and it
tends to be a 90% solution.

Possible transition path:
 * Have python3-mako provide a virtual package mako-render.
 * Perform a MBF asking those packages that use mako-render to change
   their dependency on python3-mako to mako-render.
 * Wait for 90% of the bugs to be fixed.
 * NMU the rest.
 * Split mako-render out of python3-mako and set mako-render
   M-A:foreign.

Do not dare asking whether this can be done for bookworm. Though the
first step could be done to ease backporting.

Helmut

Haha! Don't worry :-) I just happen to stumble upon it.
Thanks for the explanation and your cross-build work in general :-)