[Lazarus] An online package manager

[Tony Whyman]

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.

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.

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.

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

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.

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.

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

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

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

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

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

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

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

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

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

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.

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.


Tony Whyman
MWA