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

[Helmut Grohne]

Hi,

On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote:
> Just like lcl, lcl-2.2 is also a virtual package.

This is technically wrong. The term "virtual package" refers to a binary
package name that is provided by some package but doesn't exist as a
.deb. Both lcl and lcl-2.2 exist as .deb files and thus are called
"concrete packages".

> If I look to all other virtual packages, they are Arch: all, and I tend to agree
> with that.

Since virtual packages do not exist as concrete packages, they do not
have an Architecture field and inherit their architecture from the
providing concrete packages. I sense that your use of "virtual packages"
does not match the definitions in Debian policy section 7.5.

I guess that what you mean here is more commonly called "meta package"
or "dependency package".  Does that make sense to you?

> However, I'm not very familiar with multi-arch subtleties.

I am, but I am very much unfamiliar with Pascal, so we will only make a
dent on this if we manage to combine our knowledge.

> So if you want to fix this, please provide a proposal for then entire set of
> packages.
> 
> I would glad then to fix it.

I fear that my knowledge of Pascal is too limited here, but let me try
anway:

lazarus-2.2 and lazarus look like a metapackages. They presently are
A:all and implicitly M-A:no. That much seems fine to me. Due to
depending on lcl-2.2, they must not become M-A:foreign.

lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary
packages containing source code only are commonly that way.

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.

lcl-2.2 is A:any M-A:same. This is a metapackage for libraries and A:any
M-A:same is commonly correct for libraries.

lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary
packages containing documentation only are commonly that way.

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.

lcl is much like lazarus-ide and friends except that it is M-A:foreign
and this is what this bug report is about.

When I say "need to change" I mean an actual unresolvable dependency
that happens in some practical setting such as cross building (which is
what motivated this bug report). It seems very likely that we'll have to
work on #845498 before there is any need for lazarus, so keeping these
A:all metapackages for now makes sense to me. Just try to remember that
when someone comes a long and says "lcl-units should be M-A:foreign,
because this dependency is not resolvable" that it must not be
M-A:foreign and instead that'd be the time to convert it from A:all to
A:any. Until that happens, I think you're fine.

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

So this really is only about removing that one M-A:foreign line from
d/control. And then once we moved forward on #845498, then revisit the
other metapackages in a distant future.

Helmut