[Lazarus] An online package manager

[Michael Van Canneyt]

On Mon, 10 Aug 2015, Tony Whyman wrote:

> This is a very good idea and IMHO something that should be given a high 
> priority. However, rather than chat about solutions, I'd like to propose some 
> user requirements:
>
> 1. The Package Distribution Model should be similar to if not based on the 
> approach used for the Debian and RPM Package Managers.
>
> For example, I have my own Debian repository on an intranet that supplements 
> the Ubuntu and Mint repositories and from which I can distribute company 
> applications and backports where the standard package is not sufficiently 
> up-to-date.
>
> I would like to be able to do the same with Lazarus/FPC packages.
>

Supported by fppkg.

> 2. Packages should be similar to deb/rpm packages comprising a standard 
> archive with the files given in their installation layout, plus a list of 
> dependent packages and version information.

Supported.

>
> Unlike deb/rpm packages, the installation layout should be relative rather 
> than absolute as the target directory should be under the user's account e.g. 
> (/home/tony/.lazarus/packages for Linux). A different location may be 
> preferred for examples - which could be in separate packages.

Supported.

>
> 3. Locally installed packages (i.e. under the user account) should override 
> and replace packages with the same name installed at the system level.

Should be doable.

>
> 4. All packages in the repository should be signed (e.g. using a GPG user 
> key). Only packages signed using a known key should be allowed to install.

I don't see the point in that.

>
> 5. Access to the repository should use http/https allowing the client to GET 
> an individual package or download a list of packages and direct dependencies.

Works.

>
> 6. The package manager client should have both command line and GUI (part of 
> Lazarus IDE) versions.

Can be done with fppkg and fpmake.

>
> 7. The client should be configurable with an ordered list of known 
> repositories.

Can be done with fppkg and fpmake.

>
> 8. The client should allow available packages to be browsed/searched.

Can be done.

>
> 9. The client should manage a list of known (and trusted) signing (public) 
> keys and validate the signature on any downloaded package.

See 4.

>
> 10. Selecting a package to be installed should automatically select all 
> required dependencies, installing any that are not currently installed.

Supported by fppkg and fpmake.

>
> 11. When a runtime package is installed, the package is registered with the 
> IDE and added to the list of known packages.

Needs to be implemented.

>
> 12. When a design time package is installed, the package manager should offer 
> to rebuild the IDE.

Needs to be implemented.

>
> 13. When a package is removed, the package manager should offer to remove all 
> otherwise unused dependencies.

Needs to be implemented.

>
> 14. The package manager should support a check for updates and package 
> upgrade.

Partially supported by fppkg.

>
> 15. The IDE should be configurable to support an automatic check for updated 
> packages each time it starts. offering to upgrade any out-of-date packages.

Needs to be implemented.
>
> 16. Implementing the repository as a RESTful service could be interesting, 
> allowing packages to be added and removed using (authenticated) PUT and 
> DELETE methods in true cloud storage fashion.

Needs to be implemented, but is an interesting option in combination with the keys.

As you see, our requirements when designing fppkg are quite similar to yours.

There are only so many ways in which a useful package system can be made.

Michael.