Debian removes FPC/Lazarus

[dbannon]

Folks, as some of you already know, Debian has removed FPC/Lazarus from its Forky (ie unstable) repo. This is because they are dropping support for gtk2 and both FPC and Lazarus (appear) to depend on the much out of date gtk2 !

Why is this important ? Firstly, a large number of Linux Distros are based on Debian. And some that are not based on Debian still get source packages from there. Almost all distros are in the process of dropping gtk2 anyway.

This will be see by all Linux community. Its very bad 'optics' for FPC/Lazarus if Debian drops FPC/Lazarus (and all the apps that depend on FPC/Lazarus).

Whats the Issue ?
Its obvious how Lazarus depends on GTK2, you may well say, "just use Qt5 or Qt6" but its not that easy. The problem is that FPC also depends on gtk2 on Linux.

FPC has a package, eg  lib/fpc/3.2.2/units/x86_64-linux/gtk2/ in a binary install. That provides a number of ppu used, for example by Lazarus. Debian binaries are generated from Debian Source Packages and, presumably, gtk2 is necessary for that generating.

The easy solution of removing that package <src>packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus. Obviously, lazarus-gtk2 will break (who cares ?) but  so too does, for example, a Lazarus-Qt6 built with bigide. Apparently, all Linux Lazarus installs use the FPC "gtk2 package" files to provide -

• CairoCanvas
• Glade
• glib2
• Pango ....

Without which not too many Lazarus applications, Qt5 or Qt6 will run.

Clearly, the answer is to have a new Lazarus package containing the (non-gtk2) units from FPC's gtk2 package. That does introduce some rather messy transition issues. Especially if we cannot have a FPC release !

My ideal solution might be to have a "Linux Only Release", based on FPC324rc1, get that back into Debian and then, with the next release of Lazarus, provide the necessary files as part of LCL.

Thoughts ?

Davo

 

   

[marcov]

FPC has a package, eg  lib/fpc/3.2.2/units/x86_64-linux/gtk2/ in a binary install. That provides a number of ppu used, for example by Lazarus. Debian binaries are generated from Debian Source Packages and, presumably, gtk2 is necessary for that generating.

There is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian.

But since Debian has not really a reputation for being flexible, that probably means that the debian maintainers have to split the package again just like it was 10-15 years ago. Or they simply don't install the GTK2 headers, moving only those to a separate package.  Well, packaging things is what packagers do. 

Anyway, that is an Debian internal problem.

The easy solution of removing that package <src>packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus.

1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity.
2. Afaik Lazarus has its own headers.


Modified: typo debian->lazarus that has own headers

[Zvoni]

1. The easiest solution is if Debian simply made an exception and didn't that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity.

Or we do it like the Gambas-Boys and offer our own Repository (or like so many others), outside of Debian's control
https://gambaswiki.org/wiki/doc/packages?nh&l=en#t5

[Fred vS]

The problem is that FPC also depends on gtk2 on Linux.

Hello Davo.

Hum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux).

[dbannon]

There is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian.

No Marcov, sorry. there is a gtk2 package in FPC. Its used, eg, by Lazarus. As I just explained elsewhere, the .ppu and .o files in that package have to be generated on a machine that has gtk2 installed. That package exists in the 'official' FPC packages on Source Forge, its not a Debian invention.
 

But since Debian has not really a reputation for being flexible,

Indeed they are not flexible. They maintain over 120,000 packages, would you expect them to be flexible ?

 
1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity.

See above. 120k packages ?

Afaik Lazarus has its own headers.

I have hidden that FPCgtk2 directory and found that all my test applications, running Qt5 or Qt6 will no longer build. That directory contains files like -

Code: Pascal  [Select][+][-]

1. dbannon@dell:~$ ls -l ~/bin/FPC/fpc-3.2.3/lib/x86_64-linux/gtk2/*.ppu
2. atk.ppu
3. gdk2pixbuf.ppu
4. gdk2.ppu
5. gdk2x.ppu
6. gdkglext.ppu
7. glib2.ppu
8. gtk2ext.ppu
9. gtk2.ppu
10. gtkglext.ppu
11. libglade2.ppu
12. pangocairo.ppu
13. pango.ppu

Yep, they can be and should be moved (only the non-gtk2 ones, drop the gtk2). Thats my suggestion above. But messy transition problem. And its most certainly not just a packaging issue.  I have seen little to indicate that the Debian people will undertake anything like that.

The question I keep asking myself is why on earth do we have these files managed in FPC ?  They clearly belong in LCL. But interesting, there are also gtk1 files there 

And of course, Lazarus is an issue. We ship gtk2 lazarus from source forge. Won't be too many platforms that will run on soon.

Davo

[dbannon]

Hum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux).

OK Fred, so no "fpc-3.2.3/lib/x86_64-linux/gtk2" or, in the SRC dir, SRC/fpc-3.2.3/packages/gtk2 ? 

Do a find on, eg pangocairo.ppu for me please. It appears in all my FPC trees but not Lazarus. Probably been moved, very sensibly !

(Hmm, interesting, there does seem to be things pangocairo.ppu and cairocanvas.ppu in Lazarus, just my test project cannot find them. Will hav to wait until tomorrow .....

Davo

[cdbc]

Hi
@Davo: Here's the output from 'ldd' on a small fpGUI test-app:

Code: Bash  [Select][+][-]

1. bc@red hello-fpgui$ ldd hello-fpgui
2.         linux-vdso.so.1 (0x00007ffe4c9dd000)
3.         libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f6e970f8000)
4.         libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f6e970e4000)
5.         libXft.so.2 => /usr/lib64/libXft.so.2 (0x00007f6e970ca000)
6.         libc.so.6 => /lib64/libc.so.6 (0x00007f6e96edc000)
7.         libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f6e96eb4000)
8.         libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f6e96e63000)
9.         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f6e96da1000)
10.         libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f6e96d95000)
11.         /lib64/ld-linux-x86-64.so.2 (0x00007f6e97262000)
12.         libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6e96d90000)
13.         libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f6e96d88000)
14.         libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f6e96c27000)
15.         libz.so.1 => /usr/lib64/libz.so.1 (0x00007f6e96bf8000)
16.         libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f6e96be5000)
17.         libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6e96b87000)
18.         libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f6e96a2f000)
19.         libbrotlidec.so.1 => /usr/lib64/libbrotlidec.so.1 (0x00007f6e96a21000)
20.         liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f6e969dd000)
21.         libm.so.6 => /lib64/libm.so.6 (0x00007f6e968e8000)
22.         libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f6e9675e000)
23.         libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f6e96400000)
24.         libbrotlicommon.so.1 => /usr/lib64/libbrotlicommon.so.1 (0x00007f6e9673b000)
25.         libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007f6e9668a000)
26. bc@red hello-fpgui$
27.  

This app is compiled with 'fpGUI-1.5.0' and FPC 3.2.2 and I can't see anything GTKx related...?
Regards Benny

[Fred vS]

Hum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux).

OK Fred, so no "fpc-3.2.3/lib/x86_64-linux/gtk2" or, in the SRC dir, SRC/fpc-3.2.3/packages/gtk2 ? 

Do a find on, eg pangocairo.ppu for me please. It appears in all my FPC trees but not Lazarus. Probably been moved, very sensibly !

(Hmm, interesting, there does seem to be things pangocairo.ppu and cairocanvas.ppu in Lazarus, just my test project cannot find them. Will hav to wait until tomorrow .....

Davo

Not sure I understand.
Do you mean it's impossible to compile FPC without having GTK2 installed?
I agree that I've always compiled FPC on machines where GTK2 is installed. I'll try compiling it on an OpenBox machine without GTK2 (but I remember doing it before and FPC compiled fine).

Compiling LCL (Lazarus) is a different story.

[Fred vS]

@Davo: Here's the output from 'ldd' on a small fpGUI test-app: ...

And here the output from 'ldd' on a big MSEgui app (MSEide):

Code: Pascal  [Select][+][-]

1.  $ ldd mseide
2.         linux-vdso.so.1 (0x00007ffe9c135000)
3.         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000725c19fe4000)
4.         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000725c19fdf000)
5.         libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x0000725c19ea2000)
6.         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x0000725c19e9d000)
7.         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000725c19c00000)
8.         libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x0000725c19e70000)
9.         /lib64/ld-linux-x86-64.so.2 (0x0000725c1a00c000)
10.         libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x0000725c19e6a000)
11.         libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x0000725c19e62000)
12.         libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x0000725c19e4c000)
13.         libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x0000725c19e3d000)

 

[robert rozee]

hi Davo and Marcov,
    can i please ask a couple of questions for clarification:

1. if i build a GUI application (today) using Lazarus that targets qt5, will the resulting binary run on linux systems that do NOT have gtk2 (or any other GTK variant) installed?

2. assuming that all the 'offending' bits and pieces were moved from the FPC package to the Lazarus package, would the Debian developers then be happy with FPC?

3. similar questions, but wrt qt5 (or any other qt variant): are there qt bits contained within the FPC package? and could they similarly be moved to the Lazarus package?

4. once the FPC package has been rendered 'GTK and qt free' (and indeed free of any other widgetset dependencies), would it then be possible to create a Lazarus package that:

• contained NO binary executables or object files;
• from which FPC alone could rebuild all the binaries and object files necessary to run and use the Lazarus IDE and thence from which arbitrary Lazarus/FPC GUI applications could be built?

it just seems to me that provided...
A. the FPC package were made widgetset-free, and,
B. the Lazarus package being distributed contained JUST source code,
... then the Debian folks would have nothing to complain about.

the end user would then just need to:
1. install FPC (containing the already built FPC compiler),
2. install the Lazarus source code package,
3. run a script that builds the Lazarus IDE, library object files, etc.

both installs (1. and 2.) could be from the Debian repositories, and both packages would be 'clean'; the "build script" from 3. would generate binaries and object files that depended solely upon existing libraries already installed on the local machine.

with the resulting Lazarus IDE and object files having dependencies ONLY on widgetset(s) actually present on the system, this would be far cleaner than the present approach of distributing object files that may have dependencies not fulfillable on the system on which FPC and Lazarus have been installed.


cheers,
rob   :-)

[marcov]

There is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian.

No Marcov, sorry. there is a gtk2 package in FPC. Its used, eg, by Lazarus.

Indeed. Lazarus does use them nowadays, that must have changed. Maybe with the introduction of boolean32.

As I just explained elsewhere, the .ppu and .o files in that package have to be generated on a machine that has gtk2 installed. That package exists in the 'official' FPC packages on Source Forge, its not a Debian invention.

Not that I know, and I routinely compile FPC on headless systems. What error do you get?  Maybe you need it to link, but not the build the .ppu/.o's.

But since Debian has not really a reputation for being flexible,

Indeed they are not flexible. They maintain over 120,000 packages, would you expect them to be flexible ?

Yes.  99.9% are the same configure/make cycle, but FPC is in the other category.

 
1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity.

See above. 120k packages ?

Doesn't matter.

I have hidden that FPCgtk2 directory and found that all my test applications, running Qt5 or Qt6 will no longer build. That directory contains files like -

That is strange. What error do you get ? Maybe something (print related) using Cairo?

Yep, they can be and should be moved (only the non-gtk2 ones, drop the gtk2). Thats my suggestion above. But messy transition problem. And its most certainly not just a packaging issue.  I have seen little to indicate that the Debian people will undertake anything like that.

No, they shouldn't. We still support GTK2 for non lazarus applications for distributions that didn't remove GTK2.

The question I keep asking myself is why on earth do we have these files managed in FPC ?  They clearly belong in LCL. But interesting, there are also gtk1 files there 

Non Lazarus obviously.   

And of course, Lazarus is an issue. We ship gtk2 lazarus from source forge. Won't be too many platforms that will run on soon.

Debian maintainers can build whatever backend they want. They don't need permission from Lazarus for that.

[marcov]

it just seems to me that provided...
A. the FPC package were made widgetset-free, and,
B. the Lazarus package being distributed contained JUST source code,
... then the Debian folks would have nothing to complain about.

or (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-)

[Zvoni]

or (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-)

or (D) offer our own Repo, and package to your hearts content incl. resolving dependencies. I vote (D)

[robert rozee]

it just seems to me that provided...
A. the FPC package were made widgetset-free, and,
B. the Lazarus package being distributed contained JUST source code,
... then the Debian folks would have nothing to complain about.

or (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-)

as we have no control over the Debian folks, and is seems certain they will not make any exceptions, it does not matter how anyone votes. they (Debian) will not make an exception, and we can all 'vote' until we go blue in the face.


cheers,
rob   :-)

[ccrause]

Not sure I understand.
Do you mean it's impossible to compile FPC without having GTK2 installed?

No, the compiler binary itself does not link to a graphics library. It appears to be a secondary dependency problem: FPC provides a GTK2 package that can be used to link against GTK2 libraries.  A user could then use the FPC provided package to create a program that calls GTK2 functions, which would then require the GTK2 library to be present when linking the final executable.