<html><head></head><body><div>Hi Helmut,</div><div><br></div><div>On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi,<br></div><div><br></div><div>On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Just like lcl, lcl-2.2 is also a virtual package.<br></div></blockquote><div><br></div><div>This is technically wrong. The term "virtual package" refers to a binary<br></div><div>package name that is provided by some package but doesn't exist as a<br></div><div>.deb. Both lcl and lcl-2.2 exist as .deb files and thus are called<br></div><div>"concrete packages".<br></div></blockquote><div>Yes, indeed, you are right here, even of I question myself if we do really need to have this kind of meta package or we should just migrate to really virtual packages.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>If I look to all other virtual packages, they are Arch: all, and I tend to agree<br></div><div>with that.<br></div></blockquote><div><br></div><div>Since virtual packages do not exist as concrete packages, they do not<br></div><div>have an Architecture field and inherit their architecture from the<br></div><div>providing concrete packages. I sense that your use of "virtual packages"<br></div><div>does not match the definitions in Debian policy section 7.5.<br></div><div><br></div><div>I guess that what you mean here is more commonly called "meta package"<br></div><div>or "dependency package". Does that make sense to you?<br></div></blockquote><div>Absolutely!</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>However, I'm not very familiar with multi-arch subtleties.<br></div></blockquote><div><br></div><div>I am, but I am very much unfamiliar with Pascal, so we will only make a<br></div><div>dent on this if we manage to combine our knowledge.<br></div></blockquote><div>I don't think you need to know much about Pascal for this problem.</div><div>We just need to install a set of libraries with FPC/Lazarus and we want also to keep old version upon major version upgrade, just like GCC for example.</div><div>For Lazarus, there is a small complication, as it supports both Gtk and Qt widget sets, so we need to support installing either or both, but with Gtk2 as default.</div><div>In future, there will also be support for Gtk3, but I fear this is not yet ready for next months. </div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>So if you want to fix this, please provide a proposal for then entire set of<br></div><div>packages.<br></div><div><br></div><div>I would glad then to fix it.<br></div></blockquote><div><br></div><div>I fear that my knowledge of Pascal is too limited here, but let me try<br></div><div>anway:<br></div></blockquote><div>Let me give some background:</div><div>Lazarus is an IDE for Pascal. It comes with a huge number of libraries (called packages or components).</div><div>Upstream generates a huge unique deb package which is about 1GB size.</div><div>On Debian, we decided to split this into small packages in order to ease installation on some reduced HDD architectures.</div><div>Thus we split it into IDE, and LCL (Lazarus component libraries) packages.</div><div>We also want to keep old IDE version upon upgrade, in case someone's code breaks due to new version changes in the IDE. BTY, we do the same thing for FPC.</div><div><br></div><div>Lazarus deb package is meant to be used by those people who don't want to deal with what they exactly need, and thus installing this package will pull everything while ensuring upgrades. This is just like the gcc or kernel package.</div><div><br></div><div>More advance people can install only IDE, or only LCL tools with some components and use command line lazbuild tool. </div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lazarus-2.2 and lazarus look like a metapackages. They presently are<br></div><div>A:all and implicitly M-A:no. That much seems fine to me. Due to<br></div><div>depending on lcl-2.2, they must not become M-A:foreign.<br></div></blockquote><div>Yes, exact.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary<br></div><div>packages containing source code only are commonly that way.<br></div></blockquote><div>Yes, this is needed for optimal usage of the IDE, with automatic suggestion, but also while box debugging.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2,<br></div><div>lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and<br></div><div>lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way<br></div><div>unless there is a need for change.<br></div></blockquote><div>IDE and utils packages are providing binaries.</div><div>other ones are providing libraries, so, taking into account below comment, I'd say they should be M-A:same.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lcl-2.2 is A:any M-A:same. This is a metapackage for libraries and A:any<br></div><div>M-A:same is commonly correct for libraries.<br></div></blockquote><div>OK.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary<br></div><div>packages containing documentation only are commonly that way.<br></div></blockquote><div>OK.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units,<br></div><div>lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These<br></div><div>are metapackages and those typically have their Architecture field match<br></div><div>the one they forward to, but this is not the case here. It's not clear<br></div><div>whether this needs to change. As long as we only need it for the native<br></div><div>architecture, this can be fine. They must not become M-A:foreign though.<br></div></blockquote><div>These packages need to pull the versioned homonyme package (example: lazarus-ide-2.2) for the architecture in use.</div><div>If I <i>aptitude install lazarus-ide</i> I'd expect that <i>lazarus-ide-2.2:amd64</i> is installed on a amd64 machine, not arm or any other arch.</div><div>However I would expect to be able to install <i>lcl-units-2.2:armhf</i> for cross compilation.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>lcl is much like lazarus-ide and friends except that it is M-A:foreign<br></div><div>and this is what this bug report is about.<br></div></blockquote><div>Not exactly, because lazarus-ide pull an IDE which is a program, while lcl pulls libraries which are object files used for cross compilation.</div><div>This makes the entire difference and was a headache to fix multi-arch errors, warnings and hints in the packages tracker.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>When I say "need to change" I mean an actual unresolvable dependency<br></div><div>that happens in some practical setting such as cross building (which is<br></div><div>what motivated this bug report). It seems very likely that we'll have to<br></div><div>work on #845498 before there is any need for lazarus, so keeping these<br></div><div>A:all metapackages for now makes sense to me. Just try to remember that<br></div><div>when someone comes a long and says "lcl-units should be M-A:foreign,<br></div><div>because this dependency is not resolvable" that it must not be<br></div><div>M-A:foreign and instead that'd be the time to convert it from A:all to<br></div><div>A:any. Until that happens, I think you're fine.<br></div></blockquote><div>I forgot about this #845498!</div><div>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.</div><div>For cross compilation, one expects the user to know what he is doing and install the right packages manually.</div><div>Maybe you want to say that one can simply use <i>aptitude install lcl-units:armhf</i> and all armhf LCL packages get installed? This will indeed be a great feature.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>On the flip side, lcl presently being M-A:foreign is promising that<br></div><div>interfacing with lcl is independent of the architecture and this is a<br></div><div>lie. We should not be making this promise and thus remove M-A:foreign<br></div><div>there as it misleads a dependency resolver in finding a solution that<br></div><div>totally does not work at all in practice and causes me to file annoying<br></div><div>bug reports about your package. :)<br></div></blockquote><div>Can you please explicit with an example, so that I'm sure to understand what you mean?</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>So this really is only about removing that one M-A:foreign line from<br></div><div>d/control. And then once we moved forward on #845498, then revisit the<br></div><div>other metapackages in a distant future.</div></blockquote><div>If we do so, then the PTS will complain, but why not, I'll let you then suggest next step.</div><div><span><pre>-- <br></pre><pre>Cheers,
Abou Al Montacir
</pre></span></div></body></html>