Online Package Manager

[JuhaManninen]

Yes, the Zip file should not contain anything extra. Download traffic should be kept low.
Marc asked me for the needed size and traffic. I could only estimate it is low, even with the DB which will contain only textual data.

If the package manager causes an explosion of Lazarus' popularity, as it may happen, then the traffic could be a problem...
This will be as popular as Visual Studio or NetBeans. Millions of people install packages at the same time. The server overheats and glows red trying to serve them all.

[lainz]

Hope it does as you said 

[balazsszekely]

@Juha
Yes, the Zip file should not contain anything extra. Download traffic should be kept low.

What about documentation, demos(source only)? The total size of the 34 packages is 26.9 MB, it's less then 1MB/package. With today standard 26.9 MB it's a small footprint. Even 100 MB would be small. 

Marc asked me for the needed size and traffic. I could only estimate it is low, even with the DB which will contain only textual data.

Perhaps @Leledumbo can give us some info about the traffic. He's running the repository for almost a month.

PS: The Lazarus popularity can be increased by supporting mobile/web development and a more straightforward cross-compiling.

[JuhaManninen]

What about documentation, demos(source only)? The total size of the 34 packages is 26.9 MB, it's less then 1MB/package. With today standard 26.9 MB it's a small footprint. Even 100 MB would be small. 

Sure they can be included, as well as any resource files needed by a package. I was only worried about compiled binary files included accidentally.
Anything below 1GB is small in today's standards. I estimated a few GB will be needed even with the server SW + DB in future. Not much really.

---
Earlier there was discussion about including snapshots of development versions of some packages.
It is a diffucult issue with packages which don't have a maintainer. Nobody makes release versions of them. The Online Package Manager admin must take some revision from the commit history and "release" it. What if it crashes? Is it his responsibility to find a revision that does not crash?
This issue is a swamp.
Now initially it doesn't matter because everybody is enthusiastic. After some years however people get bored with such admin work. The packages without a maintainer are forgotten even if their master source got some fixes.
The goal is that all packages have a maintainer but it is not realistic. I was surprised to learn that even well-known packages like Synapse have no recent releases. It has a maintainer after all.

We are now solving the same problem that CCR repo tried to solve years ago. The idea was that all Lazarus packages can be found easily in one place. They are under revision control, thus their maintainers can easily develop them.
Well, it has not worked very well. Most package authors have fleed.
There is a danger that we end up with a similar outdated system. Most packages are not maintained and to get their latest fixes you must use revision control directly anyway.
Maintained packages are our hope. The Online Package Manager should be easy and attractive for their maintainers. That's why the remote URL should be supported, so that trusted sources can be updated as easily as possible.
How to make it more attractive? How to get people to maintain packages? Uhhh...

I am not criticizing GetMem's efforts obviously. I am looking to the future years ahead. The maintenance cannot depend on one person eternally, it must be made sustainable.

[lainz]

If size needs to be really low I must trim test projects that are most the size of bgracontrols, a lot of tests  nothing more than 4 or 3 mb 

About the mantainer I agree, I want to be myself that uploads the new versions directly. Then aproved or not it needs more people than only one that reviews, if is the case.

Why don't use GitHub directly, SF can't be used without the trick of the redirection (is in the wiki to get direct downloads from sf) or picking manually the mirror.

You can create a new repository called packages, create releases and put there the files and that's all. Then instead of having to upload to your server the file uses the github one (you miss the server load in this case, all goes to github) and link it to the package as is currently beign doing for the alternate download, well instead of beign alternate just main.

[JuhaManninen]

You can create a new repository called packages, create releases and put there the files and that's all. Then instead of having to upload to your server the file uses the github one (you miss the server load in this case, all goes to github) and link it to the package as is currently beign doing for the alternate download, well instead of beign alternate just main.

I think the remote URL feature already supports that.
Later a support for all GitHub repositories can be added, like Delphinus has now. It is a different concept however, it allows any package without any checks to pass. The user must be informed about it when he enables that option.

[balazsszekely]

@Juha

Earlier there was discussion about including snapshots of development versions of some packages.
It is a diffucult issue with packages which don't have a maintainer. Nobody makes release versions of them. The Online Package Manager admin must take some revision from the commit history and "release" it. What if it crashes? Is it his responsibility to find a revision that does not crash?
This issue is a swamp.
Now initially it doesn't matter because everybody is enthusiastic. After some years however people get bored with such admin work. The packages without a maintainer are forgotten even if their master source got some fixes.
The goal is that all packages have a maintainer but it is not realistic. I was surprised to learn that even well-known packages like Synapse have no recent releases. It has a maintainer after all.

For the first time, I'm not following you  . If somebody doesn't want to maintain his package, there is little you can do about it.

We are now solving the same problem that CCR repo tried to solve years ago. The idea was that all Lazarus packages can be found easily in one place. They are under revision control, thus their maintainers can easily develop them.
Well, it has not worked very well. Most package authors have fleed.
There is a danger that we end up with a similar outdated system. Most packages are not maintained and to get their latest fixes you must use revision control directly anyway.
Maintained packages are our hope. The Online Package Manager should be easy and attractive for their maintainers. That's why the remote URL should be supported, so that trusted sources can be updated as easily as possible.

The update feature will be ready tomorrow. Next week I plan to add SVN support. It shouldn't be to difficult. In a month or so the ''personal repository" feature will be also available. Everyone can create a whole repository, store it on GitHub for example. LazOpkman will be able to load multiple repositories at the same time.

@lainz
If size needs to be really low I must trim test projects that are most the size of bgracontrols, a lot of tests  nothing more than 4 or 3 mb 

Don't trim anything. Although bgracontrols is one of the biggest package, still way below the upper limit. After all is a complex package.

[wp]

Here one more ccr package: lazbarcodes. I don't use it, but I checked it with Laz trunk/1.6 / fpc3.0/trunk: compiling fine, and a simple test runs without any issues. And I remember that there are a few users here in the forum using it, I had fixed one or two issues for them. So, I think, lazbarcodes should be included.

I uploaded a "release" snapshot to the Files section of SourceForce: https://sourceforge.net/projects/lazarus-ccr/files/LazBarcodes/

[balazsszekely]

Thank you @wp!
I added lazbarcodes to the main repository.

[minesadorada]

I will have some packages to add, but first I am testing them with Laz 1.7 and fpc3.1.1, Windows and Linux.
There are UTF8 issues to tweak on some of them for instance.

[minesadorada]

In the ccr svn repositry https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/components/
There are:
1. lazautoupdate
2. longtimer
3. playsoundpackage
4. poweredby
5. scrolltext


All are currently maintained.


I was unable to package them in OPM.  I downloaded & installed today, but it crashed itself and Lazarus (Laz1.7/fpc3.1.1 Win64)  I assume it's still under development.

[wp]

@minesadorada: Thank you for bringing the attention to these nice components (the playsoundpackage has already been included).

A few questions/remarks to these components

lazautoupdate:
I saw that you distribute synapse along with this component. I don't know, but wouldn't it be better if you just provide the download link?

Or even better: As I can see (I may be wrong) you use synapse only to download files from their web sites. You should be able to do this also with fphttpclient that comes along with fpc (see folder packages/fcl-web/base). Reducing external depencies is always a good objective.

In the package file, you add the synapse.lpk package file to the "files" section of the lazupdate section. Why? I fear this will sooner or later cause trouble for those users who already have synapse installed (like myself), because it will end up in a version mixup of the already installed files and the files added by your package.

All packages:
All packages have a requirement of the ideintf package. I think this is not good because it pulls all the designtime code into your application. The correct way, in my opinion, would be to split the stuff into two packages, the runtime package containing all the runtime stuff (your unit code plus LCL), and the designtime package for the work with form editor and object inspector (ideintf plus your aboutbox)

P.S. I know that "my" tvplanit does the same - but these components were written a long time ago by TurboPower when nobody was aware of this issue, it will be fixed in one of the next releases.

[minesadorada]

@minesadorada: Thank you for bringing the attention to these nice components (the playsoundpackage has already been included).

A few questions/remarks to these components

lazautoupdate:
I saw that you distribute synapse along with this component. I don't know, but wouldn't it be better if you just provide the download link?

Or even better: As I can see (I may be wrong) you use synapse only to download files from their web sites. You should be able to do this also with fphttpclient that comes along with fpc (see folder packages/fcl-web/base). Reducing external depencies is always a good objective.

In the package file, you add the synapse.lpk package file to the "files" section of the lazupdate section. Why? I fear this will sooner or later cause trouble for those users who already have synapse installed (like myself), because it will end up in a version mixup of the already installed files and the files added by your package.

All packages:
All packages have a requirement of the ideintf package. I think this is not good because it pulls all the designtime code into your application. The correct way, in my opinion, would be to split the stuff into two packages, the runtime package containing all the runtime stuff (your unit code plus LCL), and the designtime package for the work with form editor and object inspector (ideintf plus your aboutbox)

P.S. I know that "my" tvplanit does the same - but these components were written a long time ago by TurboPower when nobody was aware of this issue, it will be fixed in one of the next releases.

Hi wp,

lazautoupdate:  I include synapse so that the component installs and works smoothly.  In my own case, if a package complains about missing stuff when I first install it, then I look for an alternative, and I suspect others do the same.  The synapse version is 40 stable, and proven to work with the component.  I have no plans to rewrite the component to use fphttpclient without a powerful reason for doing so.

All Packages:  You are probably right about designtime/runtime.  I don't worry about filesizes too much nowadays, but maybe some folk do.

In all cases, it's up to you if you want to include the packages as is in OPM.  I simply offer them as freely-licensed code which is maintained.
Of course, you are free to change/patch them if you have the time or inclination.  They are all LGPL2.

I appreciate the feedback - it's all constructive.

[wp]

They are all LGPL2.

This confuses me: You say here that the license is LGPL2, but in the license header of ulazautoupdate you write: "This library is free software; you can redistribute it and/or modify it  under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License..." - this is GPL v2, LGPL would be "GNU Lesser Library General Public License".

So what is valid? Is there a special reason why you don't select the modified LGPL (with linking exception) which is used for all (?) LCL code?

[minesadorada]

They are all LGPL2.

This confuses me: You say here that the license is LGPL2, but in the license header of ulazautoupdate you write: "This library is free software; you can redistribute it and/or modify it  under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License..." - this is GPL v2, LGPL would be "GNU Lesser Library General Public License".

So what is valid? Is there a special reason why you don't select the modified LGPL (with linking exception) which is used for all (?) LCL code?

Ah - well spotted!  I wrote the code before I properly understood licensing.  Being linkable components, they should all be modified GPL of course.
I'll edit the component source and update the svn - it's a one-line change for each component.

== done ==