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

[Abou Al Montacir]

Hi Helmut,

On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> 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".
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.
> 
> > 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?
Absolutely!
> 
> > 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.
I don't think you need to know much about Pascal for this problem.
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.
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.
In future, there will also be support for Gtk3, but I fear this is not yet ready
for next months. 
> 
> > 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:
Let me give some background:
Lazarus is an IDE for Pascal. It comes with a huge number of libraries (called
packages or components).
Upstream generates a huge unique deb package which is about 1GB size.
On Debian, we decided to split this into small packages in order to ease
installation on some reduced HDD architectures.
Thus we split it into IDE, and LCL (Lazarus component libraries) packages.
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.

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.

More advance people can install only IDE, or only LCL tools with some components
and use command line lazbuild tool. 
> 
> 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.
Yes, exact.
> 
> lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary
> packages containing source code only are commonly that way.
Yes, this is needed for optimal usage of the IDE, with automatic suggestion, but
also while box debugging.
> 
> 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.
> 
> 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.
OK.
> 
> lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary
> packages containing documentation only are commonly that way.
OK.
> 
> 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.
However I would expect to be able to install lcl-units-2.2:armhf for cross
compilation.
> 
> 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.
This makes the entire difference and was a headache to fix multi-arch errors,
warnings and hints in the packages tracker.
> 
> 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.
I forgot about this #845498!
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.
For cross compilation, one expects the user to know what he is doing and install
the right packages manually.
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.
> 
> 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?
> 
> 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.
If we do so, then the PTS will complain, but why not, I'll let you then suggest
next step.
-- 
Cheers,
Abou Al Montacir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20231225/634d4330/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20231225/634d4330/attachment.sig>