Debian removes FPC/Lazarus

[robert rozee]

I put it [...] that antagonising the Debian project will not be in the interest of the FPC and Lazarus communities, and will risk marginalising Pascal to an even greater extent than is current.[...]
MarkMLl

i strongly agree. can i please repeat (part of) the list of questions i asked in Reply #9 of this thread:

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 [itself] 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 [the 'cleaned'] FPC (containing the already built FPC compiler),
2. install the Lazarus source code [only] package,
3. run a script [shipped with the Lazarus package] that [uses FPC to] build the Lazarus IDE [ELF binary], library object files, etc.

both installs packages (1. and 2.) could [surely then] be [hosted in] 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.

i am looking at a solution SPECIFIC to x64 Linux versions for Debian of FPC 3.2.2 and Lazarus 3.8.0 (or thereabouts). the ONLY changes would be (1) removing some pre-built files, (2) changing some configuration files, adding a new 'rebuild me' script. NO version changes would be involved. this would NOT be a new branch.


perhaps my take on the situation is a little simplistic?

i would appreciate hearing feedback in particular from MarkMLl, Marcov, and Davo.


cheer,
rob   :-)

[MarkMLl]

Part of the problem is that there are three separate groups of people involved.

I think the consensus is that building FPC (as distinct from Lazarus) doesn't demand the presence of GTK v1/2/3 or Qt, even though it might build libraries capable of interfacing with them. As such, the FPC developers are blameless.

The core Debian maintainers already have a big job on their hands trying to reconcile problems caused by Wayland, Systemd and so on. The Pascal community really /cannot/ afford to antagonise them.

Whoever packages FPC into a Debian package has slipped up by assuming that because it includes GTK2 interface units it requires the presence ** of Debian's libgtk2.0-dev package: if it did then it would be impossible to recompile FPC on a non-GUI system. /That/ is where the problem lies, and /surely/ it can't be too difficult for the FPC maintainers to persuade them to see the error of their ways without upsetting the broader Debian community in the process.

Considering Lazarus: the current/stable version of Debian ("Trixie", v13) has separate packages for different IDE widget sets:

lazarus-ide-gtk2/stable 4.0+dfsg-3 all
  IDE for Free Pascal - Last GTK+ version dependency package

lazarus-ide-gtk2-4.0/stable 4.0+dfsg-3+b1 amd64
  IDE for Free Pascal - GTK+ version

lazarus-ide-qt5/stable 4.0+dfsg-3 all
  IDE for Free Pascal - Last Qt version dependency package

lazarus-ide-qt5-4.0/stable 4.0+dfsg-3+b1 amd64
  IDE for Free Pascal - Qt version

As I've said (briefly) above, I can confirm that a binary FPC (3.2.2, loaded from the FPC repo, not from Debian) is able to recompile its own sources (ditto) on Trixie without problems provided that it's got the standard ncurses etc. prerequisite for its textmode IDE. I've not however checked a recent Lazarus.

I've not checked, but I would have hoped that Debian's e.g. lazarus-ide-qt5 did not in itself have a dependency on gtk2. However that's of little use if (Debian's packaged) FPC has extraneous prerequisites, but that's the Debian package maintainers' problem rather than either the FPC developers/maintainers or the core Debian team.

I have not attempted to look at later versions of Debian: my modus operandi is heavily oriented towards SSH with X11 etc., and if Debian refuses to support that combination I will either look elsewhere or will ensure that development systems are aggressively isolated.

I'm not sure that answers all your questions (Robert), but I think it touches on most of them.

Edited to add:

** There is a possibility that the package maintainer doesn't realise the extent to which the FPC compiler includes its own build system analogous to make, and that external libraries will not be referenced unless a program imports the interface units.

MarkMLl

[marcov]

Keep opening those tickets on the debian site and voting them up till they see the light

I put it to you (Marco) that antagonising the Debian project will not be in the interest of the FPC and Lazarus communities, and will risk marginalising Pascal to an even greater extent than is current.

Not doing anything and foregoing the hope of a Debian in-distro FPC package will do so also.  And probably numbers is the only thing that gets their attention since we already discussed till we were blue in the face with the maintainers in the bugreports mentioned in this thread.

The package maintainers (Abou) are of course in a tough spot, and have navigated the disconnected between FPC's one distro vs debian's "factor everything out as a separate package" mentality for years. I suspect the package maintainers hit a wall when communicating with Debian brass too, but that is no excuse to dump it on our doorstep.

Since what goes for GTK2 also goes for GTK1 (still default compiled too!), X11, SDL etc. Just because the Debian top brass pushes for wayland and thus gtk2 deprecation this suddenly becomes an issue. Since they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years...

Anyway to my best knowledge the "fpc" port is already a meta package consisting out of smaller debian package, it would make sense to simply remove the gtk2 package from  the FPC meta package, and add a dependency on it to the Lazarus package and other packages that might use it. (I don't know exactly how they handle Lazarus switching dependencies to various gtks and QTs).

That's another way they could solve the problem themselves, anyway I'll see if I can add that suggestion to the bugreport later.

However, I also note that a number of other projects are unhappy about the direction that Debian and other distreaux are moving, in particular their deprecation of X11 (in favour of Wayland) which obviously has a bearing on things like gtk.

Probably, but that is more something for Lazarus to decide, as FPC is not really GUI orientated.

[MarkMLl]

Since they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years...

So is the real problem that (in the absence of a Makefile) that tool assumes that the presence of gtk2 interface units requires the underlying library, without understanding that if the units aren't imported they have no effect?

If necessary, could Debian's installation scripts build the questionable units? There's precedent there: libdvd being built on demand, Google Earth being installed externally and so on.

MarkMLl

[robert rozee]

what would happen if WE created an "FPC 3.2.2 x64 lite" package and submitted to the Debian folks for inclusion in their repositories? as i've said above, it would contain the exact same ELF binary of the FPC compiler, but have the GTK/qt/etc problematic bits removed. also, it would also lack any pre-built object files and other binaries (as far as possible), with these instead all being built at install-time on the user's own computer.

how difficult would this be to accomplish?


cheers,
rob   :-)

[marcov]

Since they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years...

So is the real problem that (in the absence of a Makefile) that tool assumes that the presence of gtk2 interface units requires the underlying library, without understanding that if the units aren't imported they have no effect?

I've no idea what was first, if the maintainers added some dependency to GTK2 based on some guideline and the scanner picked up on that, or that the tool simply picked up on the "GTK2" string somewhere and that was enough.  I also don't know who really deprecated the package (if it was somebody central running the scanners, or if they at least ran it over the official maintainers).

You can see here that the current FPC "gtk2" units packag. (a package that they themselves split off from the main build cycle!) depends on libgtk2.0-dev. The FPC meta package   depends on that gtk2 package.

If necessary, could Debian's installation scripts build the questionable units? There's precedent there: libdvd being built on demand, Google Earth being installed externally and so on.

They already do factor it out themselves. So I don't see why they couldn't fix this themselves. It is basically a modification in a division into packages they (or previous maintainers) created. The question is why the maintainers persist. Is making fundamental changes to the package hierarchy beyond their means? Or do they get swept up in the frantic quest to erase GTK2 ? Or do they expect that exceptions won't be accepted by high ups in the Debian chain?

I don't know. All I know is that it is a problem of Debian's creation, and they somehow want to drop it on our doorstep as ours.  I assume sooner or later there will be a suggestion to use p2c to make the "difficult" part of FPC go away (being a self bootstrapping compiler). Wouldn't be the first time they suggested that, nor the second when they had to make an exception (a binary starting compiler). A later similar conflict issue was reproducible builds, that was then heavily pushed by the central debian organisation.

[PascalDragon]

what would happen if WE created an "FPC 3.2.2 x64 lite" package and submitted to the Debian folks for inclusion in their repositories? as i've said above, it would contain the exact same ELF binary of the FPC compiler, but have the GTK/qt/etc problematic bits removed. also, it would also lack any pre-built object files and other binaries (as far as possible), with these instead all being built at install-time on the user's own computer.

There is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation that FPC also has units for GTK1 so they can just as well deal like that for GTK2. Just like marcov said they need to remove the reference from the fpc meta package to the fpc-gtk2 package and instead have lazarus depend on it (this obviously moves the issue to the lazarus package, but that is a different topic from the fpc package due to Lazarus indeed requiring some UI backend).

[MarkMLl]

There is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation that FPC also has units for GTK1 so they can just as well deal like that for GTK2. Just like marcov said they need to remove the reference from the fpc meta package to the fpc-gtk2 package and instead have lazarus depend on it (this obviously moves the issue to the lazarus package, but that is a different topic from the fpc package due to Lazarus indeed requiring some UI backend).

FWIW I agree (although I'd have written "Debian /should/ /be/ perfectly capable"), but my point is that they shouldn't be antagonized.

Edited to add: FPC has interface units for e.g. libusb, but superficial examination doesn't show a prerequisite of libusb-1.0-0-dev or libusb-dev expressed in the Debian package dependencies.

MarkMLl

[robert rozee]

There is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation [...]

while Debian is "perfectly capable of...", there remains the sticky point that Debian may choose to NOT "deal with the situation". if Debian does nothing, FPC will (from what others have suggested) be removed from the Debian repositories.

what makes everyone so certain that Debian will suddenly 'see the light'? they have little to lose, whereas for the wider Pascal community (not just FPC) the loss seems somewhat more substantial. but for a ha'porth of tar⁺ we could act to ensure FPC 3.2.2 was brought back into the Debian repositories, and once there with a little lobbying amongst the Debian-derivative distros have it even more widely available.


does anyone even care? it strikes me that the current FPC developers are more interested in tinkering with their (perpetual) beta code, while abandoning the working compiler (3.2.2) that the rest of the world has been using for the last 4.5 years.


cheers,
rob   :-(


⁺ "but for a ha'porth of tar the ship was lost" (and other similar variations)

[dbannon]

while Debian is "perfectly capable of...", there remains the sticky point that Debian may choose to NOT "deal with the situation". if Debian does nothing, FPC will (from what others have suggested) be removed from the Debian repositories.

Robert, Debian has a "Pascal Team" of several people of varying degrees of activeness. They are both committed and capable but, obviously, need to work within Debian guidelines.  In the past, Abou has been very active with the packaging of FPC/Lazarus but I have not seen anything from him for a few weeks. Another person, Mazen, seems to be concentrating on gir2pas to try and deal with the problem, I have asked for clarification but not got anywhere yet.

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel

I have a current debian unstable box that has gtk2, FPC, Lazarus and my app still available so not really sure whats happening. Lots of notices flying around saying they have been removed.

I do believe however, it will be OK. The important issue was that the dependency on gtk2 was, apparently, added to the Debian source package by mistake, perhaps a long time ago when every box did have gtk2 and it did not matter. Many people, me especially, assumed it was there for a good reason (despite being told otherwise by Marcov and PascalDragon).

Be nice to hear from someone from that team to be honest.

Lazarus is, of course, the next issue !

(My advice to anyone using Lazarus on Linux is to download and build the source, see  https://github.com/davidbannon/FPC_Laz_Install/blob/main/compile_fpc.bash)

Davo

[Fred vS]

Hey guys, why are you tilting at windmills?

Regarding "remove GTK2 (and so fpc-lazarus) from Debian," are you sure that applies to the entire Debian project? As far as I know, Ubuntu uses Debian and has several variants without Wayland (which is the number one problem): Xubuntu and Lubuntu, which certainly won't remove GTK2.

And as for the "Wayland-only" distros, well, forget about them.

[marcov]

Robert, Debian has a "Pascal Team" of several people of varying degrees of activeness. They are both committed and capable but, obviously, need to work within Debian guidelines.  In the past, Abou has been very active with the packaging of FPC/Lazarus but I have not seen anything from him for a few weeks. Another person, Mazen, seems to be concentrating on gir2pas to try and deal with the problem, I have asked for clarification but not got anywhere yet.

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel

Thanks, I read them, and some observations I considered noteworthy:

• Abou  (the current .deb maintainer) seems to understand (24 jan) that for FPC removing the gtk2 dependency from fp-gtk2units is the only short time viable option
• I only see robot messages about GTK2 package deprecations on that maillist. Seems no verdict from humans/Debian brass yet, so they might get away with that and reinstate FPC relatively quickly
• From his posts I also gather that GTK2 is deprecated absolutely (as it will not be there in testing, so moving the dependency to Lazarus won't do much good), so Lazarus will have to use something else, mostly likely some QT. Possibly even as flatpack with matched qtpas.
• Mazen (a former .deb maintainer) wants to generate headers from girs. However since I did the same for Windows to use Aravis, I know using them will break occasionally as the GIR or the translator changes how an instruction is encoded or translated. I hope they choose to long term maintain generated headers rather than regularly (or dynamically) blindly regenerating with the .gir or gir2pas du jour.

As for Fred's remark about the "entire" debian process, nearly everything debian derived uses Debian upstream. Normally such move would be death sentence to GTK2,  but since the attached Wayland subject is very political, it is hard to predict what will happen. There is also time, since trixie became stable last august, I guess we have till summer 2027, and maybe a small year before a course becomes definitive.

Even if some releases/spins will opt out, that will be hard on themselves, since they will have to do (much) more work to track upstream. It essentially becomes a fork tracking at a distance instead of a packaging spin. They might hold out a major debian cycle as a protest, but most won't last longer than one before conforming. And even if they keep X, they might not keep GTK2.

[AmatCoder]

Regarding "remove GTK2 (and so fpc-lazarus) from Debian," are you sure that applies to the entire Debian project? As far as I know, Ubuntu uses Debian and has several variants without Wayland (which is the number one problem): Xubuntu and Lubuntu, which certainly won't remove GTK2.

Why not?
GTK2 is one thing, and another thing is Wayland.
Neither Xubuntu (Xfce -> GTK3) nor Lubuntu (LXQt -> Qt6) are using GTK2 anymore...
They are still using X11 (for the time being) but not GTK2...

GTK2 will be removed from Debian in the near future.
And, of course, its derivatives as well (Ubuntu, Linux Mint etc).

Arch Linux already did it.

[Fred vS]

GTK2 will be removed from Debian in the near future.

OK (it is sad because GTK2 works very well).
So, for Lazarus, the default widgetset should be Qt.

What bothers me a bit about Qt is that the qt4pas library has to be installed and it's not possible to load it dynamically (maybe I'm missing something there).

And for Wayland,  I  .

[dbannon]

Yeah, sure, a large percentage of linux distros are Debian based. Some, like ubuntu take a regular (twice yearly) snapshot of Testing, others wait for a Debian to decide that Testing is ready (~2 years) to migrate to release and derive their distro from the released version.

Obviously, there is no reason that a Debian derived distro could not reintroduce the gtk2 libraries back into their own repos but I cannot imagine why they would bother. Similarly, a user could download and build gtk2 onto their own system. But why ?

As far as Linux Desktops that use Gnome 2, Mate and Cinnamon for example, I doubt they actually make direct calls to the gtk2 libraries that we are familiar with.  They are continuing the Gnome 2 interface, not necessarily the use of gtk2. Mate uses mostly gtk3 I believe.

Use of Wayland is inherent to a Desktop, not a Distro. My Mate Desktop does no use Wayland (yet). Gnome and KDE (infamous for using Wayland) could be rebuilt to not use Wayland. I dislike both interfaces so its not going to be me !

Davo