libQt5Pas names and versions

[dbannon]

I was about to get in touch with (Linux) Mageia to point out that their libqt5pas library is a lot of out date.  But as I was thinking about what I would say, I realised I would have no credibility.  Maybe, first, we, the Lazarus community, need to do something about libqt5pas naming and versioning ?  Substantial and very important changes have been made to this library over the last couple of years but its version number has remained 1.2.6 in fixes (1.2.8 in trunk) and the header of Qt5Pas.pro header says "Binding Release Version 2.6". That leads to confusion among the distros -

• Debian/Ubuntu call it   libqt5pas1_2.6~beta-4_amd64.deb, only the number after the 'beta' varies between versions on, eg U18.04 which won't work with Lazarus and the later ones that do.  The package name includes the '1', its not called libqt5pas, its libqt5pas1. And the "~beta" certainly confuses package managers.
• Redhat / Fedora call it qt5pas-2.6-2000601.fc31.x86_64.rpm, they have dropped the '1' altogether.
• SUSE call it  libQt5Pas1-2.0.2-lp151.1.4.x86_64.rpm - we get the '1' back but as part of the package name but not the version where it should be.  Perhaps the 2.0.2 refers to the Lazarus release they grabbed it from ?
• Mageia call it lib64qt5pas1-2.6-2.mga7.x86_64.rpm, again the '1' appears as part of the name, not the version.  And they still get their source from http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html. And that means, of course, it does not work.

In all the cases I have examined, the actual library installed ends up as libQt5Pas.so.1.2.6 with usual symlinks. Some work, some don't. Some quote the Jan.Van.hijfte site as the authoritative URL but do appear to get their source from the LCL tree. Its impossible to define a dependency that covers the variations end users are certain to encounter.

I suggest two things must change, version numbers and location ! Because of the confusion that currently exists between 1.26 and 2.6, maybe it needs to be called 2.7 until the Lazarus release catches up to 3.x, just needs to be  consistent and greater than 2.6, I like the SUSE idea of linking the version to Lazarus release. So, the package will be libqt5pas_2.7.0 and the library will be libQt5Pas.so.2.7.0  We will rev last digit for each Lazarus release until 3.0.0, then it will be just the Lazarus version.

Secondly, location, I get the impression the distro devs don't like having to look for the source in the LCL tree, after all its a standalone library.  So copy a snap shot from the LCL tree to its own repository, maybe at each Lazarus release ?  Happy to put it on my github site (along with some debs and rpm), or maybe zeljko could create a new one. It could go into the Lazarus CCR but  you cannot get just one component from there (and that's weird!). 

As Qt5 is seen as a replacement for the aging GTK2 on Linux at least, we need to make things a lot clearer. I am guessing its too late to change the U20.04 due next month but maybe ?

Davo

[zeljko]

1. libQt5Pas 1.2.6 (as packaged with distros is perfect for stable lazarus).
2. libQt5Pas 1.2.8 is trunk version (as of yesterday) and it will be for next stable lazarus.
3. About versioning numbers ...I personally don't care, whatever developers decide I'll set it up.
4. BUT trunk libQt5Pas is fully compatibile with stable lazarus one , so distro packagers can use trunk version at any time.
 Also, if they have specific questions this is the place where they can drop such questions.
5. AFAIK distro packagers take complete lazarus tree for libQt5Pas build, also eg Fedora sets that fpc-src is needed package by libQt5Pas and it's wrong.

[dbannon]

Thanks zelijko.

1. No, both Mageia 7.1 and Ubuntu 18.04 LTR ship versions of the library called 1.2.6 but they do not have any of your changes. 
2 and 4. While I understand that the trunk is a great place to find stable source for the library, the evidence is that the distro maintainers don't. 
3. The problem with version numbers is they don't change and the distros don't even agree on what we have now.
5. I had not noticed Fedora thinking fpc-src is a dependency, but does not surprise me. Sigh....

I think the distro maintainers think of the library as a development tool, but its needed by end users. Mageia is an example, its still shipping Lazarus 1.8.4. Pretty useless for anyone who reads this forum.  But there are a lot of Mageia users, if I send one of them my application (in qt) it does not need a current Lazarus but it must have a current libQt5Pas. 

I tell them it needs v.1.2.6 of the library and they say, sure, I have that. But we know that not all v.1.2.6 are created equal.  So I tell Mageia that their version is out of date and they come back and say that they have v.1.2.6 !

We have a similar problem with Ubuntu 18.04 and who knows whats in the SUSE package.....

Davo

[ChrisR]

Davo

As GTK2 is being phased out and Lazarus GTK3 sport in Lazarus is still very rough, QT5 looks like the widgets of choice for Linux Lazarus developers. The key is finding a way of sharing the bindings with users easily to ensure deployment.
 1. I like your idea of the 2.7 numbering, and then using Lazarus numbering when Lazarus > 2.7. This would clear up a lot of confusion.
 2. Is there a way to include the library as a relative path (rpath) so it could be included in the same folder as the executable, or statically including the library with the executable? I realize it is usually desirable to have dynamic libraries, and am not sure that one version of the bindings work for all versions of Linux, but this would seem to ease deployment.

[dbannon]

Thanks Chris, glad someone is interested.

Keeping the Library with the executable is really not the Unix way of thinking, executable in */bin  and libraries in */lib.

But you could do it, probably get some snide comments.  Put both library and executable in, say, ~/bin and set a path to there if necessary.   Manually call LoadLibrary() with a full filename and path should work, be pretty messy I suspect. I really think it would be a bad way to go, the "right" thing to do is fix the underlying problem.

My suggestion that we make a separate repo for it, and manage that repo would, IMHO solve the problem long term.  But without the support of zeljko and the other devs, all it would be is a pointless fork.

I suppose I could build it as a demo, if people are unhappy with it, I would tear it down again ?  I need to build some debs and rpms anyway.

But overall, there is little point in going to the big distros asking them to fix things if we cannot offer them a clear, easy to understand and implement alternative.

Davo

(hmm, I'm sounding depressed there, I think its the shadow of a certain virus ...)

[ChrisR]

@zeljko can you update the version numbering in trunk, e.g. change Qt5Pas.pro
   VERSION = 1.2.8
becomes
   VERSION = 2.7.0
as Shannon notes, this will provide a unified numbering system for all Linux distributions. Once the Lazarus version is > 2.7 we can match the Qt5Pas number to be the same as each Lazarus release.

@dbannon I strongly endorse your idea. You could have a simple repository with just the library code. A simple script could check for a.diff between your repository and the main Lazarus trunk /lazarus/lcl/interfaces.qt5/cbindings folder - if there is a difference, your repository copies the new Lazarus code and generates a new commit.

I think you are the right person to set this up. With the end of GTK2, the future of Lazarus on Linux seems to be focused on Qt5. Specifically, in my experience the Qt5 widgets is more mature (e.g. [TColorDialog][/https://bugs.freepascal.org/view.php?id=36416], [SpinEdits][/https://bugs.freepascal.org/view.php?id=34473], [Clipboard][/https://bugs.freepascal.org/view.php?id=36348] issues on GTK3). From my own perspective, the fact that GTK3 does not support Legacy OpenGL and that Core OpenGL on GTK3 does not support multi-sampling are fundamental reasons why Qt5 is a better choice for the tools I develop.

Even if you eventually tear down your repo when their is a main Lazarus alternative, your repo would provide a proof of concept and allow a transition for users as the release of Ubuntu 20.04 seems to be very close.

[dbannon]

OK, I finally got some time to look further into this. And I have found -

1. The debs from eg Ubuntu call the package libqt5pas1 because thats how library debs should be named. In our case they regard version 1.2.6 of the library to be  version 2.6 of series 1 of libqt5pas.  As noted above, some distros observe this, some don't. Accepting this model makes getting a uniform version across the distros a little easier.  Zeljan has renumbered trunk to 1.2.8, so, we call that version 2.8 for now and when we move to version 3.0.0 of Lazarus, rev it then to match. That is, it will become 1.3.0 or, in package name terms, it will be  libqt5pas1 version 3.0.

2. I have built debs and rpms using source from trunk and tested them. They make Ubuntu 18.04 work well, they make Mageia work well.  They also work fine with Fedora and recent Ubuntu but are not necessary.  However, if someone is bitten by some of the bugs Zeljan has fixed in the last couple of years, they would be useful there too.

3.  Zeljan, it might avoid some confusion if you remove the spurious version numbers that appear in the source,  in qt5.pas, we have comment, line #14, "Version : 2.6Beta ". That is apparently why Ubuntu stamps their version 'beta', we can do without that. And in Qt5Pas.pro, we have a comment, line #13, "Binding Release Version 2.6", I suggest you remove version number, its mentioned correctly, 1.2.8, on line #16

4. If no one objects, I'll put that (trunk) source and the premade debs and rpms on github.  Update either "from time to time" or at each Lazarus release ?  I would like to point the distro maintainers at this repo but only with the Lazarus developers approval.

Davo

[ChrisR]

Great! I fully endorse this. Can you provide your debs/rpms so I can test. I do require Zeljan's latest features, so want to point users to the 2.8 libraries.

[dbannon]

OK, here you go !

I have tested these packages on a range of distros, lets see if you can break one !

https://github.com/davidbannon/libqt5pas

Davo

[winni]

Hi!

Suse Tumbleweed:

Package libQt5Pas1 contains:

Version:  2.6-3.1
Erstellt am: Do 27 Feb 2020 19:03:18 CET

Winni

[dbannon]

Yeah Winni, I suspect SUSE do take regular snapshots and (cleverly) name them for the Lazarus release they get them from.

if I was all powerful (and, fortunately for all, I'm not) I'd make all the distros follow the same naming model.  But they'd need to get source from trunk, not the relevant release ....

Davo

[JuhaManninen]

Maybe a bug report + a patch would help getting the source changes through.
I also think the lib versioning should follow Lazarus versioning as they always are delivered together.

BTW, Manjaro Linux comes with Lazarus built for QT5 bindings. The package is "qt5pas  2.6.r61322-1"
The lib itself:
 $ ldconfig -p | grep Qt5Pas
 libQt5Pas.so.1 (libc6,x86-64) => /usr/lib/libQt5Pas.so.1
 libQt5Pas.so (libc6,x86-64) => /usr/lib/libQt5Pas.so

[dbannon]

Maybe a bug report + a patch would help getting the source changes through.

Not sure what you mean here Juha, this discussion is about the linux distros not knowing where or how to to get current and consistently versioned source for the library.  Its in trunk, but as I have found, its a long way from trunk to release version. And release is where the distros look.

BTW, Manjaro Linux comes with Lazarus built for QT5 bindings. The package is "qt5pas  2.6.r61322-1"
The lib itself:
 $ ldconfig -p | grep Qt5Pas
 libQt5Pas.so.1 (libc6,x86-64) => /usr/lib/libQt5Pas.so.1
 libQt5Pas.so (libc6,x86-64) => /usr/lib/libQt5Pas.so

Wow, I did not know that Manjaro was still around. Sounds like they name it much like Fedora, its probably 1.2.6 (first introduced as alpha in 2013 and still same number in Lazarus release versions) although thats a guess, they have lost the '1'.  Probably none of zeljko's recent changes.

 

[AlexTP]

So you need to inform those Linux distros about your GH repo. How will you do it?

[JuhaManninen]

Not sure what you mean here Juha, this discussion is about the linux distros not knowing where or how to to get current and consistently versioned source for the library.  Its in trunk, but as I have found, its a long way from trunk to release version. And release is where the distros look.

Maybe I misunderstood.
I thought Zeljko should change the version number in the sources in lcl/interfaces/qt5/cbindings/.
Then you would provide them in an external repo which is a good idea.
Changing the version number yourself is good, too, just needs more maintenance.

Wow, I did not know that Manjaro was still around. Sounds like they name it much like Fedora, its probably 1.2.6 (first introduced as alpha in 2013 and still same number in Lazarus release versions) although thats a guess, they have lost the '1'.  Probably none of zeljko's recent changes.

Sure it is around! It is the 2. most popular distribution in the world according Distrowatch.org's rating. MX Linux is the most popular.
Manjaro is "rolling" but very stable. Any SW release is provided within a week or two. You practically never need to install SW from outside the supported package system. If the built binaries are not enough, there is AUR.
It "just works".
The "r61322" in the package name clearly refers to Lazarus trunk commit from 5. June 2019 by Zeljko:
 "Qt: textRanges(). issue #35657"
It may well be the latest change in QT5 bindings.