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
