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.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
