Bug#769380: python3-mako: Please make the package multi-arch compatible

[Diederik de Haas]

On Friday, 17 March 2023 17:46:36 CET Helmut Grohne wrote:
> Do not dare asking whether this can be done for bookworm.

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

signature.asc
Description: This is a digitally signed message part.

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Helmut Grohne]

On Fri, Mar 17, 2023 at 03:42:59PM +0100, Diederik de Haas wrote:
> Are there any new developments/insights after 5 years?
> It would be great if this bug could be resolved.

Not much. Due to the M-A:interpreter problem python3-mako really cannot
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

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Diederik de Haas]

On Tue, 5 Dec 2017 02:37:06 +0100 "Manuel A. Fernandez Montecelo" 
 wrote:
> Hi Piotr,
> 
> 2017-12-04 23:16 GMT+01:00 Piotr Ożarowski :
> >> 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.
> >
> > please point me to the policy if it's already known what's the right
> > approach
> 
> 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 // (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
> //), /usr/share, etc. -- at least that's how I interpret it.
> 
> https://packages.debian.org/sid/all/python-mako/filelist

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

signature.asc
Description: This is a digitally signed message part.

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Manuel A. Fernandez Montecelo]

Hi Piotr,

2017-12-04 23:16 GMT+01:00 Piotr Ożarowski :
>> 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.
>
> please point me to the policy if it's already known what's the right
> approach

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 // (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
//), /usr/share, etc. -- at least that's how I interpret it.

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


Regards.
-- 
Manuel A. Fernandez Montecelo 

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Piotr Ożarowski]

> 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.

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

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Manuel A. Fernandez Montecelo]

Hi,

2017-10-22 20:07 Helmut Grohne:

On Fri, Oct 20, 2017 at 10:03:01PM +0200, Manuel A. Fernandez Montecelo wrote:

#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.


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.

[...]

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.


The issue here is that the bug kinda is under (inactive) discussion:
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.


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.
--
Manuel A. Fernandez Montecelo 

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Johannes Schauer]

Quoting Hugh McMaster (2017-10-23 14:11:55)
> On Monday, 23 October 2017 5:07 AM, Helmut Grohne wrote:
> > 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.
> In what way? Marking M-A: foreign satisfies the build-dependencies I need.
> Otherwise, I have to deal with python3-mako:i386 not found.

Marking a package as M-A:foreign has a special meaning just as Depends:foo has
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  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


signature.asc
Description: signature

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Hugh McMaster]

On Monday, 23 October 2017 5:07 AM, Helmut Grohne wrote:
> 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.

In what way? Marking M-A: foreign satisfies the build-dependencies I need.
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.

> 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.

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

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Helmut Grohne]

On Fri, Oct 20, 2017 at 10:03:01PM +0200, Manuel A. Fernandez Montecelo wrote:
> #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.

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.

> 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.

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.

> 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.

The issue here is that the bug kinda is under (inactive) discussion:
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

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Manuel A. Fernandez Montecelo]

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.
--
Manuel A. Fernandez Montecelo