I don't know about this. Although they have similar functionality the two system are completely different. Mixing them would be like mixing bananas with oranges.
No, they both deal with Lazarus packages and their dependencies and installation. Conceptually the same thing. OPM is a front-end to external packages, Lazarus has front-end code for packages in local file system. The common code installs them and maintains a package graph.
You forgot that OPM already integrates into the package system using IDEIntf API, but in a clumsy and limited way.
Mattias use critical sections when loading the packages syncing those with my threaded system is a non-trivial operation. When searching for dependencies the local package manager has all the info needed in lpks, OPM has to rely on limited info available in the main JSON.
What info is missing from the JSON? I think it is pretty complete.
The package system code must be refactored and changed obviously to understand online packages.
For this to work everything has to be moved inside the packager folder, OPM once again completely redesigned, the two dialogs somehow mixed to become one.
No no! The package-API must be extended to support it. Don't worry, I am not asking you to do it.
The benefits? Some lazy user don't have to open a second dialog to check if a package is available online. OPM was not meant to replace the "Install/Uninstall packages" dialog, it's just a tool to install as many packages you like with a button click. Until now you had to open each package, press the compile then the install button.
Now you confuse the package system (dependency management + installation etc.) and its GUI front-ends.
The "Install/Uninstall packages" is a GUI for local packages, OPM for external packages. They both can install many packages at one go but it is an implementation detail of a GUI, nothing to do with the underlying package graph code.
The benefit will be good and elegant SW design! The current integration is a poorly stitched-in afterthought.
Think of my example TAChartBgra package. A user gets an error for missing package. At the same time he can see it is available in OPM. He thinks "this system is poorly designed" and yes he is right.
Another benefit is that all the packages are in one place, with the latest updates available you don't have to go through the maintainers site.
Yes, it is the benefit of an online package manager. It is the whole point of having OPM.
Yet that benefit does not reduce the need for integration anyhow.
We can even create more GUIs for various tasks with packages if need be. They all must integrate through a proper API.
Again, I am not asking you to do it. I will look at it later.
PS: Before anything somebody must implement that fpc based cgi/fastcgi, so the database server can be used for maintaining the main repository + implement the voting system.
This is a separate and independent project from the package system integration.