An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260313/865fd1ce/attachment.htm>

(sorry, had forgotten to send as 'plain text' earlier)

user 'fifr' on forum.lazarus.freepascal.org has just reported succsccfully building the Lazarus IDE (for Linux) against Ardour's YTK, a static library based upon stripped-down GTK2 source code. this has yielded an ELF binary of the IDE that has NO external widget-set dependencies, that should therefore run on any Linux desktop supporting X11 (or, in theory, XWayland). see: ?
https://forum.lazarus.freepascal.org/index.php/topic,73590.msg578346.html#msg578346 ?
it is still early days - fifr only started working on the project last week and has in just a short time made incredible progress! there are still missing features, limitations, and bugs. but it is a start. he has reported the size of the resulting ELF binary having grown by around 4.1mb with YTK?code statically linked in to the IDE. ?
the implications are:
?
1. for the Sourceforge repositories to be able to publish a Lazarus package for Linux with an 'external widget-set AGNOSTIC'?pre-built Lazarus IDE. at the moment Linux IDEs?from Sourceforge are pre-built for GTK2. ?
2. for Linux users of Lazarus to be able to distribute ELF binaries of their work that are NOT dependent on a specific external widget-set, instead just requiring X11 (or XWayland) to be present. these ELF binaries should see a modest footprint size increase of around 5mb. ?
hopefully some of the Lazarus developers see this message, and are able to visit the above forum thread to offer fifr support in his efforts. i really do see this as a major step forward for Lazarus on Linux. ?
?
cheers,
rob? ?:-)
?
?
robert rozee
christchurch, new zealand

Your message is a little misleading.

There _is_ an external dependency: ytk. It's linked statically, but the dependency exists nonetheless.

When I read 'no external dependency' I expect the whole thing to be 100% object pascal, which it clearly is not.

Correcter would be: less dependencies on dynamic libraries.

Michael.

I was going to mention the same thing. And is that really the correct way forward? It's more like addressing the symptom than the underlying cause. So the IDE can run using ytk, but what about the applications you create? Do they also use/need ytk, or are they still based on lcl-gtk2?

I personally think the correct approach is to simply get lcl-gtk3 up to speed. It benefits the IDE and people making applications with LCL. Or improve lcl-fpgui widgetset for no external dependencies - everyhing object pascal based. Or change the default to lcl-qt.

Regards,
- Graeme -

mailinglists--- via lazarus schrieb am Fr.,
13. M?rz 2026, 12:17:

The GTK3 backend is already much more usable than two weeks ago, so that is definitely the way to go :)

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260313/0e47c20c/attachment.htm>

Sven Barth wrote

The GTK3 backend is already much more usable than two weeks ago, so that is definitely the way to go :)

That is true: first time i could compile the IDE and my SQlite project with gtk3

I try now to stay with gtk3 :-)

Regards

John

Just fill issues if you find any please.

zeljko

Of course i will do that. I am just a hobbyist so very few projects with lazarus ...

Thanks for working on? gtk3 !

John

robert rozee wrote

user 'fifr' on forum.lazarus.freepascal.org has just reported succsccfully building the Lazarus IDE (for Linux) against Ardour's YTK, a static library based upon stripped-down GTK2 source code. this has yielded an ELF binary of the IDE that has NO external widget-set dependencies, that should therefore run on any Linux desktop supporting X11 (or, in theory, XWayland). see:

FWIW i did something similar some time ago with the Gtk1 widgetset, this little tool here:

http://runtimeterror.com/tools/piecemod/

has a Gtk1 version that is statically linked against Gtk1. Since Gtk1 libs can be 'officially' linked statically, all i had to do was to modify the gtk/gdk bindings in FPC to replace the $linklib directives so they point to the static libraries (unfortunately when it comes to linking, FPC only seems to provide an all or nothing approach, you can't pick and choose what to link statically and what dynamically at build time).

That said, one issue with both Gtk1 and YTK (and statically linking Gtk2) is most likely the license: LGPL. Statically linking against a LGPL library (without a static linking exception) requires from the developer to either publish the source code or make the object files for relinking against the toolkit available (i'm not sure how/if this one can be done with an FPC program). Not much of an issue for an opensource tool like the one linked above as the source is already there (and zlib is compatible with LGPL) but it can be an issue for something more 'default'.

Related, recently i took a jab at making a widgetset for FLTK which is a very lightweight toolkit written in C++ that is still developed (and has Wayland support, for those who care) and is mainly designed to be linked with statically (it is under LGPL but has an exception for static linking), though i only went as far as getting a few buttons on screen before losing steam :-P

https://i.imgur.com/W6XbLkr.png

(the cut off button is intentional as it was used to test that clipping works - FLTK has some weird ideas of its own on how to do some things)

Of course from the perspective of someone wanting "Pascal Purity" this goes even further away as not only it uses C++ (for the toolkit) but also a C bridge so that it can be used by FPC - together with some hacky build script for the bridge so that the toolkit is linked statically in the Lazarus application :-P.

(as a sidenote, the Pascal bindings for Qt can also be linked statically, i'm not sure why they're even built as a dynamic library in the first place as, unlike Qt6 itself, that adds a dependency that is unlikely to exist in end user systems -- see the tool i linked at above, it also has a Qt6 version that only relies on Qt6 libraries)

Personally right now i'll probably keep on using Gtk2 by default and if distros end up removing it, i'll build it by hand like i do with Gtk1 and consider either continuing the FLTK widgetset or switching to Qt6 with statically built bindings as the only mainstream toolkit whose UX i dislike more than Gtk3 is Gtk4 :-P

The LCL widgetset bindings should be a plugin system. Then any new widgetset?could be registered and used without including the code in Lazarus distribution.

Currently there are 2 pure Pascal LCL widgetsets, Customdrawn and LCL-FpGUI, but neither of them works well and they are not maintained. They also could be maintained elsewhere and registered as plugins if needed.

This is not a trivial task of course. The?widgetset binding code uses some nasty tricks.

The plugin system for external components and?IDE extensions works quite well.

Juha

Juha Manninen wrote

The LCL widgetset bindings should be a plugin system. Then any new widgetset?could be registered and used without including the code in Lazarus distribution.

I do not think this is a good idea because anything that doesn't get the most focus will bitrot and become much harder to bring up to date down the line. By being part of the main code, it becomes much easier to ensure things are less likely to break, especially for something as "core" to Lazarus as the widgetsets (e.g. not to long ago i brought up Gtk1 up to date so it can be compiled and used because there were already stubs and affordances in the widgetset agnostic part of LCL for stuff added later).

If anything, at least personally i avoid using anything outside the core Lazarus distribution for anything i need to work in the long term because i trust the Lazarus devs to keep things working (this is why i do not use anything from the online package manager - i do not feel i can rely on the things there being around after whoever makes them decides to abandon them). Or at least, if something doesn't work, i could submit a fix and know it'll be less likely to break in the future.

Currently there are 2 pure Pascal LCL widgetsets, Customdrawn and LCL- FpGUI, but neither of them works well and they are not maintained. They also could be maintained elsewhere and registered as plugins if needed.

If anything, these two cases are more likely to benefit from being part of the core Lazarus distribution (and IMO FPGUI should be vendored in, both to ensure it works out of the box and to avoid any breakage from API changes that i think FPGUI occasionally does) - as by virtue of being "native Pascal" any changes to the widgetset agnostic parts will be easier to test and ensure they work.

Of course for this to be the case in practice these widgetsets need to first reach a minimum level of usefulness, but i remember reading a post in the forums by Graeme recently that someone was working on restoring LCL-FPGUI with the current version of FPGUI.

Kostas

Sorry Kostas but the reality is very different from what you write.

Lazarus contains lots of crappy abandoned code. Those 2 widgetsets,?Customdrawn and LCL-FpGUI, are good examples. They have been abandoned for many years and I haven't seen or heard anything that would change the situation. They are not abandoned?because they are "ready". Their authors just made some experimental pre-alpha quality code and then lost their interest, maybe hoping somebody else will fix their mess.

Many of the included IDE extension plugins and components are of questionable quality, too. Just go through them all and you will see. In the early days of Lazarus project the threshold for including a package was lower, and later the threshold for removing them is high. For example LazReport?has a poor design and?should be maintained elsewhere and provided as an alternative for other reporting components through OPM.

On the other hand, OPM provides many well maintained and high quality packages. OPM was the missing piece for a long time but now it is there.?At least my idea is to have a slim and light Lazarus distribution and then extensions provided through OPM. It is also a way to differentiate from CodeTyphon which has an opposite philosophy.

Kostas, you should study what is available and maybe adjust your view.

Regards, Juha

I already wrote that "Of course for this to be the case in practice these widgetsets need to first reach a minimum level of usefulness", i.e. acknowledging that at this point they aren't that useful (but as i also wrote, Graeme mentioned here that someone is working on the LCL-FPGUI:

https://forum.lazarus.freepascal.org/index.php/topic,73559.msg577642.html#msg577642

I'd agree with removing some stuff from the codebase if they're making things harder for the project's development (using a few extra KBs of code isn't doing that IMO), but i think that should be of the sort of "nobody uses that in practice, nobody tried to improve it in the last decade and everybody thinks it should be gone" removal *at the least*. Personally i haven't worked with every single part of Lazarus (e.g. i never used reports so i can't judge their quality) but i can't think of something that should be removed like this. Maybe the customdrawn widgetset? But even then, i'm not sure as i think some people used it for making Android apps so even if it doesn't work now, if someone cared it could be at least be brought to a state where it'd be useful even if as a MVP approach.

Many of the included IDE extension plugins and components are of questionable quality, too. Just go through them all and you will see. In the early days of Lazarus project the threshold for including a package was lower, and later the threshold for removing them is high.

My point is that by virtue of them existing there, it becomes easier for people to rely on the stuff that *works* because there is a much higher likelihood for them to keep working in the future. And at the same time stuff that is broken (i know there are a lot of weird stuff already in the codebase) can be easier to be worked on in a fixed state for people who want to work on them.

The aforementioned LCL-FPGUI situation where someone is working on restoring it with the current FPGUI codebase is a good example of this (assuming the work will happen):

1. If the LCL-FPGUI widgetset code is part of Lazarus itself, all one needs is to fix it, submit a PR and have it be a working component of Lazarus. Future changes will only need to be applied there using the same method as any other Lazarus fix towards the same organization/people as any other Lazarus fix. End users can simply use it by selecting the widgetset from their project settings. It'll be something people can rely on (again assuming the work Graeme refers to in the post above is done - but actually even if it isn't someone else could do it if they wanted at some point in the future).

2. If the LCL-FPGUI widgetset code is not part of Lazarus, the first roadblock will be that people wont even know of its existence. Then even if they do learn of it and someone decides to improve it, since it'll be outside the code tree, they'll need to play catch-up with all LCL changes. Any improvements/fixes to it will also need to be submitted to a separate entity than the Lazarus repository, thus fragmenting effort. And this is not even taking into account the situation where some improvement in LCL-FPGUI needs modifying code outside LCL-FPGUI -- that is, some requirement for it may need applying changes to two separate entities, thus further complicating development and introducing unnecessary friction towards improving LCL-FPGUI.

3. If the LCL-FPGUI widgetset is a separate project (i.e. #2 is the status), then it means there are different people who work on it with potentially different priorities. If at some point it becomes of production quality that could have been alongside the other widgetsets, by virtue of being a different project by different people, it can introduce friction towards merging these projects (the merge should be desirable from the end users' perspective as that'd simplify their use of it).

Replace LCL-FPGUI with any other widgetset that doesn't receive much focus these days - or really any other component (i use the term in general, not as TComponent descendant :-P). There is a reason why the Linux kernel, for example, wants all drivers to exist in the kernel source code tree despite having a module system - and that is to ensure everything remains compatible and keeps working while they change the kernel's internals and is under a single place where people can contribute to (consequentially, drivers outside the kernel tree do tend to bitrot after a while, which is really the fate of anything "3rd party").

CodeTyphon sounds exactly what i'd prefer (if i ignored that it is a fork that relies on Lazarus work) because the idea of a "slim and light Lazarus" that relies on OPM to me sounds like a plan to make sure a lot of stuff will become broken down the line. OPM may have well maintained (high quality is debatable) packages, but as these are not part of Lazarus, i cannot rely on them remaining well maintained in the future. In fact i can already find a bunch of them that haven't been updated in a long time (though they may still be working - is there any automatic CI in place to check if the packages available for download at least compile with the current FPC and Lazarus?).

FWIW this isn't a unique problem to OPM, pretty much any language/environment with an online package manager ends up with this sort of "abandoned dependency hell", which is why i tend to avoid those. The thing i like with Lazarus is that it is "batteries included" and the included batteries tend to work for a very long time (and TBH personally i'd rather fix the included batteries if possible). That i have code i wrote 20+ years ago that still keeps working is a positive thing i often bring up when i talk about Lazarus.

Kostas, you should study what is available and maybe adjust your view.

My view is based on the idea of not breaking stuff that works and avoiding relying on stuff that breaks. This means minimizing dependencies where possible and 3rd party packages introduce additional dependencies, both direct (the packages themselves) and indirect (the packages they rely on), with each one being a potential point of breakage. And at the same time, pushing stuff out and forcing them to become "3rd party" means they'll inevitably become broken with no chance of redemption.

I had to build some Python software recently that relied on a package vomit of dependencies and a few of them just Would Not Build because they relied on some specific python version which was not available for download from my Linux distro's repositories, so i had to create a VM, build Python itself there, then build the dependencies on top so i can get the program to work. And this wasn't some exceptional case, this is why Python has "virtual environments" (the venv package that comes with Python itself) which essentially copies everything in a single directory in case dependencies break.

OPM might not be at the point where you'd need a "Lazarus venv" since it hasn't gained much use by the community (unlike Python's PyPI), but this is where such systems lead to.

Kostas

Kostas Michalopoulos wrote

(but as i also wrote, Graeme mentioned here that someone is working on the LCL-FPGUI: https://forum.lazarus.freepascal.org/index.php/topic,73559.msg577642.html#msg577642

Indeed, I was approached by someone asking if they can contribute to lcl-fpgui. I explained I am not the official maintainer either, and they should approach the lazarus devs here, and that such a contribution would normally be welcomed.

Based on these messages, I assume they haven't reached out yet.

ps:
I was never the original author of lcl-fpgui widgetset either. I just stepped in for a while to keep it moving forward.

Regards,
- Graeme -

Kostas Michalopoulos via lazarus kirjoitti 17.3.2026 klo 1.31:

You have a point here. A package inside Lazarus sources must support only the current trunk development version. Maintaining a package outside Lazarus sources requires support for current trunk + preferably 2 last release versions. A maintainer must either use IFDEFs sometimes or create many versioned packages (AFAIK OPM supports this).

However the situation is not as bad as?your Python experiences. (I haven't used Python much myself).

In other cases we must agree to disagree. Lazarus repository is not a magical place where everything gets fixed and maintained automatically. No, there is plenty of code that nobody touches or cares about.

It is possible to have a functional system to deliver 3rd party packages. Finding and installing a package should be transparent, as easy as installing a package from Lazarus sources.

The current OPM is not perfect though. It is updated by a middle man. Its GUI is not integrated with the other package installer GUI etc. There is room for improvement...

Juha

Juha Manninen wrote

However the situation is not as bad as?your Python experiences. (I haven't used Python much myself).

It isn't, the Python experience is one of the worst on that aspect but it is the end game of pretty much all online package managers where people are expected to rely on separate 3rd party devs to maintain their direct and indirect dependencies. See also npm as another situation of dependency hell.

In other cases we must agree to disagree. Lazarus repository is not a magical place where everything gets fixed and maintained automatically. No, there is plenty of code that nobody touches or cares about.

I didn't claim anything like that though, in fact most of what i wrote is about code that does *not* currently work and the various forms of friction introduced by separating that stuff as separate projects outside Lazarus itself. But even when it comes to working code, there is also the benefit of being easier to keep it working if it is part of the codebase (which is also something i explained). This doesn't mean the fixes happen magically, there is still someone needed to write/fix the code, but there is much less friction to do that and have the fixes available to everyone.

Kostas

That rely depends....

If we assume in both cases that someone does the maintenance, then... If it is in the Lazarus codebase (a repo controlled by the team), then patches/MR must be filed, and they will add to the workload of the core team. The more code is in the core repo, the more time of the team will be taken just by dealing with patches.

On the other hand, the current way of distributed means that each add-on relies on an external maintainer - often a single individual - to keep it up to date, even if patches are supplied.

In both cases, the ultimate goal would have to be that others become active enough in maintaining that package, so they will make it to "direct commit rights". That again needs prior work by the current team/owner/3rd-party, to establish if a candidate fits the spirit. So until established? it loops back to the above.

In any case, since either way relies on contribution (either by the original 3rd party creator / or by other contributors), the difference in who is hosting it may have less of an impact than thought. If the 3rd party repo is no longer updated (be it the creator became inactive, and does not even accept new contributions / or any other reason), then if there are contributors they can fork it. All that is needed, is a good way to recognise at which point OPM should then switch to the fork.

Look at MSE/IDE => sadly the owner passed away. But there was interest, and the project lives on.

-----------------------
Anyway, there is another part to the issue, and again it depends little on where the code is hosted, or who controls that.

Right now, when a Lazarus release comes out, there isn't even knowledge which OPM package works. And which may have already got fixes, but did not update the OPM data.

So what is really needed is a team of testers. A team of people who when they see an RC for the next release, will test each and every package. Find any issues, check for a good revision upstream, contact the maintainer, ....

And again, if the code was in the core repo (or any repo controlled by the core team) that would still be the same. As you noted (not part of the quoted reply above), "being in core does not guarantee this". And yes, I can confirm, there is code in the core repo that has probably not been tested in a long time (e.g. I doubt any one in the core team has used SynUniSyn). I do maintain SynEdit, but I have no idea if SynUniSyn currently works. I just can't get the time for it. And likely there is more.

----------------------
So instead of moving more code to core, which if indeed it has any chance of helping, will only have that chance if the core team takes the extra work of dealing with more patches.... And that automatically means that time is taken off other work....

Instead of that, if someone is interested, start improving the distributed model. E.g. start testing before releases, and contact all the owners that need to act. And establish projects that can be deemed dead, and may need to be forked...

If extra manpower exists, IMHO (big big IHMO) that is a more promising way to use it.
If no extra manpower exists, then there is no point in moving where the code is hosted.

Martin Frb wrote

And yes, I can confirm, there is code in the core repo that has probably not been tested in a long time

The above is probably the most worrying thing you said in your post (below), and IMHO argues the case for a review of OPM and non-core packages and how they are maintained and distributed.

I would guess that back in the day, distributing non-core packages alongside core code was the only viable way of distributing many useful add-on packages. On the other hand, it is not a good idea to put out a new release of Lazarus when the distribution may contain code that has not been verified and tested as part of that release. This does not give confidence in the product.

OPM seems to work well - at least as a distribution mechanism for add-on packages and it probably should now become the distribution mechanism for all non-core packages - perhaps a new Lazarus installation should prompt the installer to download and add a recommended selection of add-on packages, both to get them going and to introduce OPM to new users and the rich selection of packages available.

However, I would also suggest that there needs to be some more structuring about how packages are presented and labelled in OPM and how they are maintained. For example:

1. There should be an entry level to OPM to which anyone can contribute but which has no quality guarantees associated with it. This entry level should be clearly marked so that anyone using such a package is aware of the above, but it does give a way for new developers to get into creating and distributing packages.

2. There also needs to be at least two tiers of "quality" add-on packages: e.g.
?"Gold" tier packages have wide community use, a known set of maintainers, a comprehensive test plan and are multi-platform verified prior to the release of each Lazarus release.

"Silver" tier packages?wide community use, a known set of maintainers but lack the resources to fully test the package for each new Lazarus release.

There may even be a "relegation zone" for packages that that have been in the main tiers but which no longer appear to be maintained - and are open for someone to pick up and maintain.

Any other ideas?

Add automated tests of all the packages in OPM:
Test whether they can be downloaded and compiled, tests run.

This should not be hard to add, and at least you can then notify users when some package is known not to work.

Michael.

The alternative is to drop them, but if any part of them is actually still useable and used....
E.g. gtk1 (the very very old), was announced to be no longer maintained, and only being "shipped as is".

Also, if it is shipped it offers the possibility to report bugs, and then (at some time) getting fixed.

But adding more to that list (by moving more packages into core (rather than using OPM) does not help.

I haven't looked at what is there already... But if not, then there should be some sort of tags to say
- approved by maintainer for Lazarus version
- tested (by established tester)

So any package that is not known could be shown with a warning.

Again, not sure what is already there...

That creates endless debates which tier a package should be in there. We don't have stats on "how many users". And equally we don't wont to judge contributors (how to do that in an objective way?).

Even, how many commits in the last 12 month, may be misleading. It may not have any, if it simple still works.

The best measure is test results. (and usually if the maintainer says it works for version X then that is equal).
Test results by the not-maintainer would require a (group of) regular testers. Similar to translators, where many(some) languages have a dedicated person to maintain them.

But, it all starts and end with someone volunteering to do the job.

El 18/3/26 a les 11:06, Martin Frb via lazarus ha escrit:

Even, how many commits in the last 12 month, may be misleading. It may not have any, if it simple still works.

I have some components that I didn't touch in 10 years and they still work with the latest lararus release.

Bye

Tony Whyman via lazarus kirjoitti 18.3.2026 klo 11.44:

Who will verify and fix all that code? Me? Martin? Maybe you?

Another option is to drop the poorly maintained parts but that is the very opposite of what some people (Kostas) want.

Or maybe Lazarus project should stop making releases, just like FPC project did.

Who makes?a "recommended selection"? I vote for *you* to be a new OPM master. You can go through the packages, make a list and publish it in a place of your choosing. It can be part of the installer if you want.

Are you going to maintain that system? How do you study the "wide community use" status? Will you send inquiries to people?

Any other ideas?

I proposed an idea when OPM was under construction. Users could send feedback and give stars to packages. From 1 to 5 stars maybe. There are technical problems involved however. How to differentiate real users from bots and spam etc.?

Still, it can be implemented if somebody does the work. Maybe a project for you Tony.

Regards, Juha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260318/6d0bfcc1/attachment.htm>

Martin Frb wrote

The alternative is to drop them, but if any part of them is actually still useable and used....

Dropping packages from OPM is a very difficult decision - I think I never did this while I am maintaining OPM. The problem is that there is no return, the OPM packages are not stored on a kind-of-github site where a previous state can be restored. Deleted - and it's gone...

And many people seem to forget: OPM is accessible from any Lazarus version released with a built-in OPM. And in the Linux world users often work with very old Lazarus versions where a package might be working although it fails with today's Lazarus.

I completely agree with Juha. People are just talking and have many ideas. But nobody is doing any work. Nobody seems to be aware how big the number of more than 350 lpk files is. I just ran my batch file which checks every package whether it still compiles. There were about 60 for which compilation aborted. Even 60 is a huge number. It means I'd have to contact almost as many authors or internet sites some of which I don't even know. I'd be busy for quite some time. Sorry, this has to wait, I have more interesting things to do in my free time. But it would be a good job for somebody who really wants to help.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260318/dd374e95/attachment-0001.htm>

Are there any plans to put OPM in a GitLab repository? This would simplify access for users and serve as a backup.?And if OPM downloads directly from GitLab, this will reduce the load on the FP site.

I sometimes search OPM and CCR packages to make decisions before submitting certain patches (e.g.?whether a certain function?is used by at least one package). I can easily download CCR from SVN, but for OPM, I had to manually download all the packages. And I don't know how out of date my copy is. If there was a repository, I could easily clone them and see the changes later in commits.

GitLab would also allow for the automatic compilation check and test running in the pipeline that Michael mentioned.

By the way, there's now a new repository ?Lazarus Packages? in https://gitlab.com/freepascal.org/lazarus. Could these ideas be combined? Currently, packages from it can't be easily made available from OPM, as users must know about it and manually download and install it from GitLab. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260318/98ac1efb/attachment.htm>

I think that would be a good idea. And as mentioned, it would enable automated testing using CI/CD.

Michael.

n7800 via lazarus kirjoitti 18.3.2026 klo 21.18:

Are there any plans to put OPM in a GitLab repository? This would simplify access for users and serve as a backup.?And if OPM downloads directly from GitLab, this will reduce the load on the FP site.

No, the concept is that those packages are maintained somewhere, preferably under revision control, and then the author provides a release version for OPM. Currently it happens through a middle man which is not optimal.

Putting those release versions again under another revision control system would be dummy.

I sometimes search OPM and CCR packages to make decisions before submitting certain patches (e.g.?whether a certain function?is used by at least one package). I can easily download CCR from SVN, but for OPM, I had to manually download all the packages.

OPM should have an option to download every package.

And I don't know how out of date my copy is. If there was a repository, I could easily clone them and see the changes later in commits.

Ideally a released package should have both a version number and a release date.

Stuff from ?Lazarus Packages? is delivered to OPM just like from any other repository.

Wp mentioned OPM has packages which are not maintained anywhere. They should be placed under ?Lazarus Packages? or deleted completely if they are not good.

I also think it is time for a cleanup cycle for OPM. All packages should have a version number, release date, info about the author and about?the repository where it is maintained.

If a package is not under revision control, its author could be offered to use??Lazarus Packages?.

Totally abandoned packages should be just deleted.

Juha

Juha Manninen wrote

Totally abandoned packages should be just deleted.

And anything that depends on them should just break regardless of the code works or not :-).

IMO if you *really* want to rely on an online package manager, the manager should do the complete opposite: keep all previous version available so that at least if something breaks, people can use the older versions. And both packages and their dependencies should expose a version for both their dependent packages and of Lazarus, FPC and LCL and the OPM UI in Lazarus should only show compatible packages by default (but allow the user to override).

Someone running an old version of Lazarus shouldn't be a roadblock to using some online package: OPM should simply provide the compatible package(s).

Whatever their other faults are (like normalizing breaking dependent code), other package systems already do that so these concerns have already been solved by other projects.

Kostas

I might be up for that - although I am well aware of the challenges faced by anyone not part of the core team proposing changes that affect the core.

If I did get involved, my vision would be to create an environment where it would be possible for Lazarus to be installed by a "network installer". That is to create an environment where Lazarus is a set of packages, including the core IDE,? which is downloaded compiled and installed by the installer. The user can then select and installed more packages from a comprehensive code library of user provided code, and at any time thereafter (the installer then becomes the OPM client). Upgrades should use the same route with automatic dependency package resolution (including advice on which packages have not yet been tagged as supporting the new version of Lazarus - prior to performing the upgrade).

Werner has pointed out:

I read this as being that version management should be a critical part of any future OPM. I propose that a derived goal should be that each package is held on a git repository (such as github or gitlab) and version tagged for each Lazarus version that the maintainer claims support, so that you can download a version compatible with your version of Lazarus or just the latest version.

OPM is then a central database that records the repository URL used for each package, version tags, dependencies and user feedback (such as "stars").

Of course, if I was driving this, the database would be Firebird accessed using an IBX based client and providing a RESTful service created from Indy, IndySecOpenSSL and Oauth2 - but then we all have our prejudices ;)

Is there a list of the OPM packages that don't compile?

Welcome to package dependency hell :-)

Michael.

By the way, another advantage is that instead of sending a message to " " the author can create?a merge request.

More importantly, I remembered how users complained that they couldn't use the old version of a package because the new one broke something. If they didn't have a backup of the package, their project would remain uncompileable. Git easily solves this problem.

Unfortunately, I'll have to download a second copy of all the packages and compare them manually??Package versions still won't show changes as "patches".

Stuff from ?Lazarus Packages? is delivered to OPM just like from any other repository.

Each package can have its own metafile, which specifies the location of the original source code.?This means that packages are considered "readonly" unless otherwise specified. Otherwise, they accept patches.

In this metafile, can indicate that the package is unsupported and deprecated. Such packages can simply be hidden by default in the OPM window and only appear when explicitly configured or with a warning. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260319/fa3b7f2d/attachment.htm>

To summarize all the issues, I'll mention that the purpose of the CCR isn't clear to everyone. It contains many copies of OPM packages, some of them different versions or even with unique patches.

The CCR is hosted on SourgeForge under SVN, but there's also a project in the GitLab group, but without files, only for the bug tracker. SourceForge itself also has an (abandoned) bug tracker.

The only difference is that the CCR also contains projects as well as packages. Again, duplication ??another repository with projects already exists: https://gitlab.com/freepascal.org/fpc/projects. And even another one of dubious official status: https://gitlab.com/fpcprojects.

Explanations can be given to users about the differences between these repositories, but questions will continue to be asked again and again?

Multiple different locations for the same thing creates many questions for users and complicates support. Therefore, I believe it's worth considering merging them.

Different repositories also create migration issues. If a package is no longer maintained by its author and is transferred to the ?community?, it will have to be moved to another repository. With a single repository, changing just the metafile will suffice. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260319/e3ac6418/attachment.htm>

Rolf Wetjen wrote

Is there a list of the OPM packages that don't compile?

I just updated the test and got the following log file, every entry corresponds to an lpk file which cannot be compiled. Of course, when a library consists of several packages and the first one fails the other ones will fail, too.

EControl (econtrol_package.lpk)
RX (rx_sort_fbdataset.lpk)
RX (rx_sort_ibx.lpk)
ABProjectFiles (abprojectfiles.lpk)
ACS (laz_acs_directx.lpk)
ATSynEdit_Ex (atsynedit_ex_package.lpk)
CastleGameEngine (castle_base.lpk)
CastleGameEngine (castle_components.lpk)
CastleGameEngine (castle_window.lpk)
CastleGameEngine (alternative_castle_window_based_on_lcl.lpk) ExtendedPackages (lazextcore.lpk)
ExtendedPackages (lazextbase.lpk)
ExtendedPackages (lazextbuttons.lpk)
ExtendedPackages (lazextcomponents.lpk)
ExtendedPackages (lazextcomponentsimg.lpk)
ExtendedPackages (lazextcopy.lpk)
ExtendedPackages (lazextpascal.lpk)
ExtendedPackages (lazextinit.lpk)
ExtendedPackages (lazextnet.lpk)
ExtendedPackages (lazextnumeric.lpk)
ExtendedPackages (lazextreports.lpk)
ExtendedPackages (lazextweb.lpk)
ExtendedPackages (lazextwebbase.lpk)
ExtendedPackages (lazregisterdbnet.lpk)
ExtendedPackages (lazregisterdbnetserver.lpk)
ExtendedPackages (lazregisterextcomp.lpk)
ExtendedPackages (lazregisteribx.lpk)
ExtendedPackages (lazregisterzeos.lpk)
GLScene (GLScene_BASS.lpk)
GLScene (GLScene_CgShader.lpk)
GLScene (GLScene_FMOD.lpk)
GLScene (GLScene_NGD.lpk)
GLScene (GLScene_ODE.lpk)
GLScene (GLScene_OpenAL.lpk)
GLScene (GLScene_Physic_native.lpk)
GLScene (GLScene_Physic_newton.lpk)
GLScene (GLScene_SCL.lpk)
GLScene (GLScene_WinOnly.lpk)
JPLib (jplib.lpk)
JPPack (jppacklcl.lpk)
LazProfiler (LazProfiler.lpk)
LuiPack (luicontrols/jsonzvdatetimemediator_package.lpk) LuiPack (luicomponents/luifptest.lpk)
LuiPack (cairo/cairoimaging_package.lpk)
LuiPack (cairo/cairofpgui_package.lpk)
LuiPack (luicairo/luiimage_package.lpk)
LuiPack (luicairo/luiimage_package_fpgui.lpk)
LuiPack (chronolog_package.lpk)
LuiPack (librereport_package.lpk)
LuiPack (luiapp_package.lpk)
MORMot (mormot_cross.lpk)
OnGuard (tponguard_fpgui.lpk)
PascalSCADA (pascalscada_db.lpk)
PascalSCADA (pascalscada_full.lpk)

All fair points IMHO, though they have to be assessed by the team, once details emerge.

But one point in case you go that route. Those points may need to be addressed separately, as they concern different areas of maintenance....

- There is what the OPM provides, how it gets there, how its tested... => I.e., OPM
- There is when someone updates the installation (because it affects installers, or IDE startup code)
? ?- update and rebuild OPM
? ?- rebuild core packages (from packages directory) ? ? ?Currently on first start they are not build into the updated IDE, and the user has no note how to get them back.
- The size of the current installer.
- Leaving out, where code should live, that is currently in core

The last point will have its own debate... At least I guess.

Still, if someone updates they re-install e.g. all images that they already have.
And on a new install, everyone gets the sources for building the help (most only need the compiled help), the tools to build the installer, ...

And yes, it could be broken down more.
But then the installer would need the option to run again, and update... (I don't know how well that will work on Linux/Mac...)

Also, about the win installer (if you are up for it).
- It (for now) is intentionally kept on an older INNO version.
- It always needs admin rights, in case someone installs QT libs into system (32 bit installer only, iirc)
The latter could be changed by launching a sub installer, that asks for admin when launched. And it would only be launched if chosen by user. But then the build process must build that first, and then include it into the outer installer.

A useful model may be the apt installer that is used for debian linux. This installer is configured with a list of repositories and their security keys, and downloads from each one a list of packages provided, descriptions, versions and dependencies. These lists are merged together to create a local directory of available packages. The user selects a package (or packages) they want to install, and the installer works out the dependencies, downloads the packages, installs the files and then runs any configuration scripts that are part of the package.

The installer can also manage updates and uninstalls.

This would seem to be a good model that ensures robustness by allowing multiple alternative repositories, security and for managing dependencies. It also allows users to include their own local repositories in the list of known repos.

Translating this into a Lazarus installer,e.g. on Linux, the OS Lazarus installation package (deb or rpm) would install the Lazarus installer binary, the initial repository list and?the OS Lazarus installation package?dependencies would include the Free Pascal Compiler packages and (e.g.) libgtk2. A Windows installer package would do the same thing but may, in this case include the FPC binaries and GNU utils (as it does today).

Once the install is complete, the OS installer runs the Lazarus installer which then proceeds to build its package lists and downloads the most recent version of the Lazarus-IDE core package plus configured dependencies (core packages) and then proceeds to compile and install the packages it has just downloaded. As with APT, the Lazarus installer could be run multiple times, on subsequent invocations it runs in update mode.

A useful feature of such an approach could be that (e.g.) gitlab and github could each host package lists for the Lazarus packages hosted (by each one's git repository) on that platform, thus avoiding any dependency or load on a central server. These lists would be managed by the OPM Maintainer.

A recent thread with a similar issue: https://forum.lazarus.freepascal.org/index.php?topic=73682 ( https://forum.lazarus.freepascal.org/index.php?topic=73682.0 ) -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260319/b6a22913/attachment.htm>

Hi Werner,

just downloaded all OPM packages. Seems that something is wrong in your list. My local repo of today doesn't have files?jplib.lpk and?jppacklcl.lpk. Didn't check the other ones beside of?LazProfiler.lpk (to crosscheck) which is in.

Rolf

Tony Whyman wrote

If I did get involved, my vision would be to create an environment where it would be possible for Lazarus to be installed by a "network installer".

It should be possible to install a full version of Lazarus ("full" meaning that it'd contain at least the same stuff as it does today) without requiring internet connection, preferably as a single executable, like it is today.

Personally i keep offline copies of many older Lazarus releases in case they're necessary and i find myself occasionally installing Lazarus in computers and -more commonly- VMs that do not have (nor should have) Internet access.

Kostas