[Pkg-pascal-devel] Bug#1026719: Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory

[Abou Al Montacir]

On Sun, 2023-01-01 at 21:45 +0100, Samuel Thibault wrote:
> >   • Technically, Lazarus doe snot need libgtk2.0-dev for running, and thus
> >     should not pull it.
> 
> Lazarus itself, no indeed. But the fp-units-gtk2-3.2.0 package does not
> make any sense without libgtk2.0-dev, since there is no way to use the
> former without the latter.
That was the reason why fp-units-gtk2-x.y.z made dependent on the libgtk2.0-dev.
However, with deprecation of gtk2, we decided to relax that constraint.
Of course, one can argue, as you do, that the bindings packages does not make
sens without depending on the libraries package.
That makes sense, but we discussed this and relaxing the dependency was the
easiest way for us, given that FPC does not seem to be ready to provide bindings
for gtk3.

> >   • Technically, FPC does not need any GTK related lib, it only provide
> > binding
> >     units.
> 
> Yes, and *all* languages that provide bindings do provide the required
> pulls so that users of the bindings don't have to care about what
> should be pulled. The information is recorded in only the bindings
> package, and not sprinkled over all packages that happen to use it
> (which would require changes in all of them for no good reason whenever
> the underlying C library happens to change its C API, for instance).
I tend to agree here.
> 
> Things were just working perfectly previously. Why breaking the build
> of packages using fp-units-gtk2-3.2.0 by dropping the pull? Is there an
> *actual* reason for not making fp-units-gtk2-3.2.0 pull it,
Yes, the reason is to close the
bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967348

>  how does it
> hurt in any way? Is that because fpc-3.2.0 happens to depend on it?
> Then why does it do so, since from what you say it does not actually
> need it?
fpc-x.y.z is a meta-package that is there to pull all packages created by the
fpc source package.
> 
> Really, I don't understand: fp-units-gtk2-3.2.0 does need libgtk2.0-dev
> to work at all, while you are saying that fpc-3.2.0 does not need
> fp-units-gtk2-3.2.0 to work. The current "Depends" that are set on those
> package are exactly the inverse of that...
You are confused between fpc as a meta-package and fpc as an executable.
The package depends on all fp-units-* created by fpc source package.
While the executable (compiler) does not.
> 
> >   • For building, Lazarus build depends on libgtk2.0-dev, until it will
> > migrate
> >     to gtk3. And so shall do all programs that use it.
> 
> Yes, sure. But for bookworm we'll apparently stay with gtk2, so let's
> make that that works, at least.
Maybe this makes sens, but I can't revert a decision made by the team on my own,
because a user decided something else.
I'll wait for feedback from others.
> 
> > I hope this makes it clear, why neither Lazarus, nor FPC or any of their
> > packages should pull libgtk2.0-dev package.
> 
> No, not at all.
> 
> > You should handle this bug in VMG, and probably the best way to do it is to
> > build depend on libgtk-2.0-dev
> 
> From point point of view it's not the best way since it means that'll be
> yet something more to change when switching to gtk3, then to gtk4, etc.
> while everything could be just handled in the bindings package.
Yes, ideally it should be that way. In practice, I'm not sure it will be
possible. 
> 
> > until you fix [2]https://bugs.debian.org/cgi-bin /bugreport.cgi?bug=967799
> 
> That only boils down to making lazarus support gtk3, since vmg just
> uses LCL. If Lazarus was providing a gtk bindings package which does
> not encode the 2 vs 3 notion, the vmg package would be more than
> happy to just use it and not have to care at all about the underlying
> incompatibilities.
-- 
Cheers,
Abou Al Montacir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20230101/389a9470/attachment-0002.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/20230101/389a9470/attachment-0002.sig>