Unmaintained packages in OPM

[wp]

There is a variety of packages in OPM which are not actively maintained (i.e. no response to bug report or PM). This is fine unless such packages are affected by changes in the Lazarus or FPC so that they do not compile any more.

In many cases (such as in the recent removal of the "deprecated" mark) the fix is easy, and I decided to copy the most recent code from the original sites into our "Extra-Packages" repository. At the moment these are

• Code-Librarian
• EvsSimpleGraph
• EyeCandyControls
• fortes4lazarus
• textviewer
• uEControls

These packages were fixed, and there is a chance that they will be fixed also in the future provided that the fix is "easy".

The following packages are not maintained, too, and do not compile with Laz/main and probably also not with the upcoming v5.0:

• LazProfiler
• LuiPack
• pl_Cindy
• pl_ExControls
• RingWatch

These packages are techniqually too complex (LazProfiler), too large (LuiPack), originate from CodeTyphon (pl_cindy, pl_ExControls) which I refuse to touch, or are missing files (RingWatch). These packages now have been marked in OPM as "orphaned" - they do not have a package icon in the package list any more. They cannot be used with Laz/main/5.0+ unless somebody takes ownership.

[avra]

The following packages are not maintained, too, and do not compile with Laz/main and probably also not with the upcoming v5.0:

• pl_Cindy
• pl_ExControls

I just checked OPM versions on 4.8 with 3.2 fixes and both compile and run example without issues. Cross compile to x64 works as well.

[dsiders]

The following packages are not maintained, too, and do not compile with Laz/main and probably also not with the upcoming v5.0:

• pl_Cindy
• pl_ExControls

I just checked OPM versions on 4.8 with 3.2 fixes and both compile and run example without issues. Cross compile to x64 works as well.

Version 4.8 is not version 5.0.

[avra]

Version 4.8 is not version 5.0.

Are you saying that 5.0 is the current official version of Lazarus, or that OPM components should support unofficial or trunk versions of Lazarus and/or FreePascal?

[dsiders]

Version 4.8 is not version 5.0.

Are you saying that 5.0 is the current official version of Lazarus, or that OPM components should support unofficial or trunk versions of Lazarus and/or FreePascal?

They're giving you a heads up that 5.0 is coming soon... and these packages won't compile.

[Thaddy]

@wp

For what it is worth, I fixed compilation of the ringwatch components, but they look terrible, so can remove... If somebody needs them for some reason I attached the fixed sources.

[wp]

The following packages are not maintained, too, and do not compile with Laz/main and probably also not with the upcoming v5.0:

• pl_Cindy
• pl_ExControls

I just checked OPM versions on 4.8 with 3.2 fixes and both compile and run example without issues. Cross compile to x64 works as well.

That's not the point. OPM packages are not tied to any version because OPM exposes the same packages to all versions of Lazarus. Most users certainly would request compatibility with the current releases, fixes and maybe with trunk (because these will be the next releases). There are always incompatible changes in the Lazarus and FPC code base so that there is a risk that packages will not be usable any more. Therefore it is indisputable that packages are maintained so that they can be adapted to such changes.

The pl_XXXX packages were converted by you from CodeTyphon, I had contacted you some time ago and had told you about the incompatibilities. But I did not get any feedback. Therefore, I am considering these two packages which do not compile with Laz/main as unmaintained. But I'd be more than happy to remove the "orphaned" tag if you update them from the current CodeTyphon where they probably will compile.

[n7800]

The following packages are not maintained, too, and do not compile with Laz/main and probably also not with the upcoming v5.0:

• LazProfiler

I was able to compile LazProfiler in trunk. There are still runtime errors, some of which I’ve fixed. There are other open, unanswered suggestions in this topic that are also worth pursuing. I don't know how stable it can become, but we won't know unless we try...

If a "fork" of it appears in the new package repository, I’ll create an MR.

[wp]

Does this mean that you are willing to maintain it? This would be great! In this case you should fork the code into your own github/lab or whatever, fix the issues and, when you are done, send me a message to opm@lazarus-ide.org.

[avra]

OPM packages are not tied to any version because OPM exposes the same packages to all versions of Lazarus.

PL components are a moving target since both FPC and Lazarus trunk are used by CT, and components are modified in each version. so there had to be a decision whether to support official Lazarus/FPC or trunk. You can find it here:
https://forum.lazarus.freepascal.org/index.php/topic,39508.msg274330.html#msg274330

The pl_XXXX packages were converted by you from CodeTyphon, I had contacted you some time ago and had told you about the incompatibilities. But I did not get any feedback. Therefore, I am considering these two packages which do not compile with Laz/main as unmaintained. But I'd be more than happy to remove the "orphaned" tag if you update them from the current CodeTyphon where they probably will compile.

Somehow I either missed that message or forgot about it, so I apologize for no feedback. The answer would still be the same - I support only official Lazarus version. Even with all the automations using ct2laz and fpcupdeluxe, last time it took me 8 full working days to find and test CT component versions that fit official Lazarus and FPC, many had to be patched by myself, and few had to be unchanged from the previous release - usually because of the too big mismatch with FPC that could not be patched. I am not willing to take that kind of work for unofficial Lazarus version, so keeping these packages orphaned is fine with me.

If anyone is willing to update any of the PL components on his own, instructions are at https://bitbucket.org/avra/ct4laz.

[n7800]

Does this mean that you are willing to maintain it? This would be great! In this case you should fork the code into your own github/lab or whatever, fix the issues and, when you are done, send me a message to opm@lazarus-ide.org.

Your first message stated that you had fixed the compilation of certain packages and moved them to the "extra-packages" repository, so I expected you to do the same for LazProfiler.

I will definitely create an MR for it, but the entire Lazarus team will be able to review it, not just one person, which will be the best guarantee of its future.

[Lazazouwu]

Just to clarify my position: yes, I’m willing to work on LazProfiler and contribute the fixes needed to make it usable with current Lazarus versions.

However, I would prefer this to be handled as a community-maintained package rather than becoming the responsibility of a single maintainer. LazProfiler is complex enough that having changes reviewed and tested by several Lazarus developers would, in my opinion, give it a much better chance of remaining compatible in the long term.

I’ll continue fixing the issues I encounter and will submit an MR once the package is in a reasonable state. From there, everyone interested can review, test, and improve it.

That seems more sustainable than simply transferring ownership from one person to another.

[wp]

From there, everyone interested can review, test, and improve it.

Do you mean to open your repository for anybody? If this is possible at all, I am afraid you'll soon have porn in it...

[n7800]

From there, everyone interested can review, test, and improve it.

Do you mean to open your repository for anybody?

Note that this is the user's first comment, and it looks like AI spam that’s just clumsily mimicking the previous comment ))

... and I decided to copy the most recent code from the original sites into our "Packages" repository.

By the way, the repository link can now be updated (though the redirect still works).