[Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Mon, Dec 25, 2023 at 10:16:13PM +0100, Abou Al Montacir wrote:
> On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> > lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2,
> > lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and
> > lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way
> > unless there is a need for change.
> IDE and utils packages are providing binaries.
> other ones are providing libraries, so, taking into account below comment, I'd
> say they should be M-A:same.

In principle, I agree here. For them to become M-A:same they must first
become A:any as M-A:same is not valid for A:all. The question that is
not clear to me is whether this is worth the effort, i.e. whether it
poses a practical difference to any actual use case. And of course the
answer to this question may change over time.

> > lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units,
> > lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These
> > are metapackages and those typically have their Architecture field match
> > the one they forward to, but this is not the case here. It's not clear
> > whether this needs to change. As long as we only need it for the native
> > architecture, this can be fine. They must not become M-A:foreign though.
> These packages need to pull the versioned homonyme package (example: lazarus-
> ide-2.2) for the architecture in use.
> If I aptitude install lazarus-ide I'd expect that lazarus-ide-2.2:amd64 is
> installed on a amd64 machine, not arm or any other arch.

That all works both with A:all and A:any. The property you want is valid
as long as these packages are not marked M-A:foreign regardless of their
Architecture field.

> However I would expect to be able to install lcl-units-2.2:armhf for cross
> compilation.

What you cannot do currently is install lcl-units:armhf on an amd64
machine (because lcl-units is A:all and implicitly M-A:no). As a
downstream of lazarus, you typically do not want to encode the version
(and ddrescueview does not), so the build dependency will likely be
lcl-units rather than lcl-units-2.2 (or in the case of ddrescueview lcl
rather than lcl-2.2). If you want to support cross compilation, all of
these likely have to become A:any.

> > lcl is much like lazarus-ide and friends except that it is M-A:foreign
> > and this is what this bug report is about.
> Not exactly, because lazarus-ide pull an IDE which is a program, while lcl pulls
> libraries which are object files used for cross compilation.

My comparison of lcl ad lazarus-ide was done on a rather abstract level.
The supposed similarity is that they both are empty A:all packages
depending on other packages from src:lazarus. I did not mean to imply
functional similarity.

As you say, lcl ensures presence of libraries. I imply here that those
libraries are architecture-dependent. Hence lcl must not be M-A:foreign.
It is this M-A:foreign that actively breaks the cross compilation use
case that you supposedly try to address using it.

> This makes the entire difference and was a headache to fix multi-arch errors,
> warnings and hints in the packages tracker.

I happen to be the author of the multiarch hinter. Please go into
further detail as to what kind of errors you were faced with. Also note
that in the presence of wrong Multi-Arch annotations (such as the case
of lcl), the hinter will also give you wrong warnings. It very much is
crucial for the correct operation of the hinter to remove this
M-A:foreign.

I appreciate more detail on what went wrong here.

> For the M-A: foreign, I don't see what is the issue here. lcl-units is an A:all
> package, so you can install whatever version it will be the same.

The problem with M-A:foreign is that it masks a dependency constraint.
When you install Build-Depends of a source package, you may choose the
host architecture (i.e. the one you are building for) and all of your
Build-Depends implicitly get requested for that host architecture. When
I natively build for amd64 on amd64, I want my lcl-units dependency to
install lcl-units-2.2:amd64. When I cross build for armhf on amd64, I
want my lcl-units dependency to install lcl-units-2.2:armhf! While the
package content of lcl-units is the same, the dependency is quite
different. If lcl-units is A:all M-A:no (as is currently the case), it
cannot satisfy the :armhf dependency on amd64 and cross build dependency
resolution fails. If it were to become A:all M-A:foreign (wrong), it
would satify the lcl-units:armhf dependency and install
lcl-units-2.2:amd64 which is very much not the thing I wanted.

> For cross compilation, one expects the user to know what he is doing and install
> the right packages manually.

Not at all! For the cross compilation use case, we expect that
dependency resolution works normally and that no manual intervention is
required.

> Maybe you want to say that one can simply use aptitude install lcl-
> units:armhf and all armhf LCL packages get installed? This will indeed be a
> great feature.

Yes, exactly. This is not actually hard. It is following a relatively
simple rule of thumb to get there: A dependency package or meta package
should use the same Architecture and Multi-Arch value as the package it
depends on. If you follow this rule, you get it mostly right. The rule
breaks down when your package depends on multiple packages with
different field values. In that case, A:any beats A:all and M-A:same
tends to beat M-A:foreign.

Would you also want to do this conversion?

> > On the flip side, lcl presently being M-A:foreign is promising that
> > interfacing with lcl is independent of the architecture and this is a
> > lie. We should not be making this promise and thus remove M-A:foreign
> > there as it misleads a dependency resolver in finding a solution that
> > totally does not work at all in practice and causes me to file annoying
> > bug reports about your package. :)
> Can you please explicit with an example, so that I'm sure to understand what you
> mean?

Non-trivial. The issue is deeper than this. We have multiple resolvers
in the archive and dose-builddebcheck actually finds such a nonsensical
solution. Hence https://crossqa.debian.net/src/ddrescueview scheduled a
build and apt was too confused about this and gave up. It's not like
there is no solution for apt. If you install lcl before satisfying
ddresuceview's B-D, apt actually succeeds. The solution merely is too
complex for apt to consider. But then the solution also is wrong,
because lcl (and its dependencies) are installed for the build
architecture which is not what we wanted for cross compilation.

Once you remove M-A:foreign, dose will correctly identify the lack of a
solution and building ddrescueview will no longer be attempted. Once you
change lcl and a number of other packages to A:any, there may be a new
solution that actually makes sense as it now installs the host
libraries.

> If we do so, then the PTS will complain, but why not, I'll let you then suggest
> next step.

Yes, please. As you say this, I now guess a possible sequence of events
that made this happen (hypothesis).

At some point for some reason lcl was only depending on M-A:foreign
packages. Hence, the hinter was suggesting to also mark lcl M-A:foreign
(relying on the correctness of those other M-A:foreign). At the same
time, it may have been complaining that those other M-A:foreign packages
were wrongly marked M-A:foreign given that they contain libraries. If
you applied all the hints at that point, we'd arrive at the situation
where we are today. Removing those wrong M-A:foreign annotations would
also remove the hint for lcl. Hence removing M-A:foreign from lcl will
not cause any hint to appear now.

This may or may not be correct. We shall see. Thanks for bearing with
me.

Helmut