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