[Cross posted on forum so if you want answer there : http://forum.lazarus.freepascal.org/index.php/topic,29284.0.html[1]]

Hi,

I saw Embarcadero's Getit[2]?that introduced in Delphi XE8 and I think it can help Lazarus and it's community very well. As you know these days more IDE's make this systems and its good,collecting all packages and make it easy to use like a store. Is there any work on this subject until now or any one like to work on this subject? If yes I want to help.

Regards, Ara

Links:

1. http://forum.lazarus.freepascal.org/index.php/topic,29007.0.html
2. http://docwiki.embarcadero.com/RADStudio/XE8/en/GetIt

Aradeonas wrote

Is there any work on this subject until now

Yes, the Free Pascal project has had something like that for years, called fppkg. Unfortunately there is only 3 or so packages in there (at least the last time I checked, some 3 years ago), and they don't seem to accept more, or they are waiting for something - but I'm not sure what exactly. The FPC team also don't seem to promote also created a LCL based gui-frontend to it, but again I have no idea who is maintaining the server that fppkg talks to, or how to actually submit packages into it.

[~]$ fppkg list
Name Installed Available
embweb - 0.9.1-968
gecko - 2.9.0-3
jquery - 0.9.0-842
lazmkunit - 0.9.3-1
lnet - 0.6.6-2606
webdesign - 0.9.0-906

Ah, now there are 5 packages. :)

Regards,
- Graeme -

It seems there is need for a new one.If any one want to help or have a point for me tell me so I consider it.

Regards,
Ara

Aradeonas wrote

It seems there is need for a new one.

I don't think there is technically anything wrong with fppkg that a new one is needed. The FPC team simply needs to be more forthcoming about it and let developers know if and how they can submit new packages. I have quite a few I would like to add to it.

But yes, if the FPC team are not interested in running such a package system, then setting up a new server is probably the way to go. I haven't looked, but I'm pretty sure the fppkg code is all open source too, so making it point to a different location or making it configurable or something should be easily doable.

Regards,
- Graeme -

Probably if I understand it I will use it or maybe make a new one on it. As Marco always said if you want it so make it your self and the team are very busy so id I can I will,but I should investigate on it first. So as I said if any one of team member or others have point before I make it please say so I dont go the wrong way or consider what they say.Including you dear Graeme.

Regards,
Ara

Fppkg is working fine. Technically it is OK.
It is well integrated with fpmake (as intended).

What is missing is manpower to set up a website, repository and whatnot.

If you want to help set up a repository, website for submissions and whatnot, that would be very much appreciated.

Michael.

Ok I will read more about it.

Regards,
Ara

Aradeonas wrote

Is there any work on this subject until now or any one like to work on this subject? If yes I want to help.

The fppkg is for FPC packages. It does not work with Lazarus packages. There is a GUI for fppkg in Lazarus named LazarusPackageManager but it is broken. It should be fixed or removed.

We need a similar system for Lazarus packages and maybe other Lazarus resources. The idea is not new and there is even some skeleton code for it in package "Aarre". Nothing functional yet unfortunately.

Studying this issue has been on my ToDo list for long. Some open questions :

1. How much synergy with fppkg should it have? Can it share code?

2. Meta-package file format? I guess it should be a GZip package containing Lazarus package sources + other metadata. What other resources should be supported? More metadata is needed.

3. Support for user comments and votes for the packages. The GUI in Lazarus must support adding and viewing them.

4. List of servers. Initially it should be CCR but can be extended. The ideal situation is that all package authors provide such meta-packages somewhere.

5. A website. Is it needed to find the packages and advertise them? This may have synergy with fppkg again.

If you are serious about this project, you should study the issue and make a plan with some diagrams even.
I believe a SVN branch in Lazarus repo can be organized if needed. If fppkg code must be refactored and then reused, it may be easier to first fork it and then later offer to FPC project as a patch.

Regards,
Juha

I would make this more complicated than absolutely necessary.

lpk files have version and dependency information. AFAIK that is all you need to get a minimum working package manager using a central repository although i'd like to see multiple repositories that provide packages (f.e. personally i'd prefer to host my own packages on my server).

IMO what needs to be done is quite simple:

1. Have the downloadable packages be a zip file (tons of tools can make them, Lazarus can read them, etc) with the package directory as it should be after installation, with the lpk and all.
2. Once a package is uploaded to a repository, it should extract the lpk file so that it can show information about the package in a web view and...
3. Lazarus can download a list of available packages from a repository and when requested, it will download the lpk file to show the details. Once the user decides to download a package, the full zip is downloaded with the dependencies (if they are not already installed) and have them extracted in some place (user designated or just C:\lazarus\downloaded or something like that) and the lpk files installed.
4. Done. Restart Lazarus for the new stuff to take effect.

I know that there might be some minor issues or things people would like (like multiple lpk files or even separate metadata file, a format with better compression, a better gui, etc) but really those can be done later and IMO the majority of packages will work just fine with this setup. The other things like comments, rating, etc can also be done later.

I think that if something is going to be done, it needs to be the minimal work that needs to get things going because otherwise, it will get stalled (and it has been a while I hear about an online package installer :-P).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150809/2be0fe15/attachment-0001.html>

Of course I meant that I would *NOT* make this more complicated than necessary...

On Sun, Aug 9, 2015 at 3:47 AM, Kostas Michalopoulos <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150809/21a0222f/attachment.html>

Thank you Kostas yes it will begin simple but it should be ready for all the options. Juha yes you are right and I will get your help ;)

Regards, Ara

Aradeonas wrote

Thank you Kostas yes it will begin simple but it should be ready for all the options. Juha yes you are right and I will get your help ;)

Yes, I also want to see this feature soon.

This process may have unexpected problems which are already solved in fppkg. That's why I think fppkg should be studied well.

Juha

Me too.

Regards,
Ara

It may be rather easy using HTTP or FTP download like fppkg is doing. Some of its code can be used.
The package list must be one file (just like fppkg uses) to minimize server load.
The package format cannot be shared with fppkg though.

I don't think the server load will be a problem. The packages contain only textual source files and are compressed. They will be small enough.

Allowing users to comment and rate the packages may be the most difficult part but it is not needed initially. It will require authentication and dealing with malicious attacks and whatever. Read-only is easy.

Aradeonas, if you start to implement this, you should reuse the fppkg code as much as possible. The design looks good.
The fpmake related stuff and the package format cannot be reused. Also the client must be a Lazarus IDE package with a nice GUI instead of a cmd line program.
Looking good so far ...

Regards,
Juha

"Kostas Michalopoulos" wrote

I would make this more complicated than absolutely necessary. lpk files have version and dependency information. AFAIK that is all you

need to get a minimum working package manager using a central repository although i'd like to see multiple repositories that provide packages (f.e. personally i'd prefer to host my own packages on my server).

IMO what needs to be done is quite simple: 1. Have the downloadable packages be a zip file (tons of tools can make

them, Lazarus can read them, etc) with the package directory as it should be after installation, with the lpk and all.

I would make even simpler by not requiring to zip and upload to a server the package and corresponding files. I would download from the SCM ( git/svn) directly, like bower does. The data necessary to register the package would be name, description, dependencies, the SCM type, and the repository URL.

Luiz

2. Once a package is uploaded to a repository, it should extract the lpk

file so that it can show information about the package in a web view and...

3. Lazarus can download a list of available packages from a repository

and when requested, it will download the lpk file to show the details. Once the user decides to download a package, the full zip is downloaded with the dependencies (if they are not already installed) and have them extracted in some place (user designated or just C:\lazarus\downloaded or something like that) and the lpk files installed.

4. Done. Restart Lazarus for the new stuff to take effect. I know that there might be some minor issues or things people would like

(like multiple lpk files or even separate metadata file, a format with better compression, a better gui, etc) but really those can be done later and IMO the majority of packages will work just fine with this setup. The other things like comments, rating, etc can also be done later.

I think that if something is going to be done, it needs to be the minimal

work that needs to get things going because otherwise, it will get stalled (and it has been a while I hear about an online package installer :-P).

On Sun, Aug 9, 2015 at 2:11 AM, Juha Manninen

> > On Sat, Aug 8, 2015 at 4:27 PM, Aradeonas

> > Is there any work on this subject until now or any one like to work on

this

resources.

> The idea is not new and there is even some skeleton code for it in > package "Aarre". Nothing functional yet unfortunately. > > Studying this issue has been on my ToDo list for long. Some open

questions :

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150809/b76c255e/attachment-0001.html>

Im agree with?Luiz,Its better to have them in a server as a pack,because as you (Juha) said we dont want do any force dependency on anything like Git or Github so we can cache the packages in a server as a zip but for a job like this I want to read previous and others work completely and make a stable structure for future but?we should use?previous?works.

Regards, Ara

luiz americo pereira camara wrote

I would download from the SCM ( git/svn) directly, like bower does. The data necessary to register the package would be name, description, dependencies, the SCM type, and the repository URL.

I would suggest the same idea. Take a look at how the FreeBSD "ports" system works. Much can be learned from that.

For those that don't know FreeBSD ports system, here is a short explanation:

* The ports information lives in a directory hierarchy. The first level defines the group in which each packages belongs: eg: devel, editors, games, audio etc. Then inside those you have a directory for each package.

* Each package directory contains a couple of files and one "files" directory:
- distinfo: lists the source archive name, its size and SHA256 checksum value
- Makefile: describes the version number of the package, category the package belongs too, where the port can be
downloaded from (straight from SF.net, Github etc), package maintainer's email address, dependencies
and compiler options (user configurable at build time).
- pkg-descr: full multi-line description of the package
- pkg-plist: full list of installed files (including path information)
- files/ any small patches that get applied to the unpacked source archive before it gets compiled.

The whole "ports" directory hierarchy lives in a code repository. The end-user (developer in this case) can update their local copy from time to time. Package source code (release archives) get downloaded directly from each projects original location on SF.net, Github, etc. Unpacking the source archive for compilation happens in a temp directory inside each package directory in the ports tree. Packages can also be marked as Broken or Suspended for various reasons (eg: original source archive is not available for download any more)

For Lazarus, the ports repository is the only "bandwidth" the Lazarus server will use. A gui front-end can be written to update and search the local ports tree.

A star rating system (optional) would probably need to be implemented at the GUI front-end level, and could submit a rating via some web service. Login could be made optional, but a simple registration will most likely reduce "spam" and allow to keep track of who made ratings against what packages.

Regards,
- Graeme -

Thank you for the explanation Graeme.
I think its better to archive each version in Lazarus host or a central is better way but get them when updated from the source so prevent problems like availability , think as as a sync central, because as I saw always be here and stable is a major points of Lazarus and one of the reason I like it so much,it always there for you ;) . About users probably we can use forum users info but let see what happen.

The most important part is it make easy to use packages and sharing them so increase the power of community and get more attention on each other work and attract new users to this brilliant space ;)

I'm researching about all same services ,next make plan and structure after reading exist codes and then invite every people that want work on some part of this if they want.

For now I'm interested in community opinions so keep them in mind while the researching and planning.

Regards,
Ara

Aradeonas wrote

Im agree with Luiz,Its better to have them in a server as a pack,

No, Luiz suggested the opposite, to download from SCM directly without any packs.
I don't know why people are obsessed with SCM tools for a feature that does not need them and certainly should not depend on them.

because as you (Juha) said we dont want do any force dependency on anything like Git or Github so we can cache the packages in a server as a zip [...]

Dependency on Github web site / service is OK.
Dependency on Git tool for all Lazarus users in a no-go.

In fact I like the FreeBSD ports system. Does it depend on SCM tools or does it download some ready made Zip packages from GitHub and other sites?
Both ways have a problem : It is easy to get only the latest version of a package. Projects can depend on old versions, too.

Anyway we should add support for different download sites for the Lazarus packages, in the spirit of FreeBSD ports.
Maybe like this :

Phase 1 :
Support zipped meta-packages but allow to download them from any URL (HTTP or FTP).
The difference to Kostas' minimal design is that the Lazarus .lpk files are not needed separately. The client can extract them and check dependencies. Having dependency info in other places would be duplicate info.
A list of available packages must be in one file. Doing a FTP directory listing eats resources.
Note: no server side SW is needed.

Phase 2 :
Support also downloading from sites hosting code (SF, GitHub etc.) when they provide direct download.
Using the SCM tools directly cannot be supported because we cannot impose such a dependency for the cross-platform Lazarus. Still no server side SW is needed.

Phase 3 :
Support user rating and comments for packages.
Support using the SCM tools from server. When a download URL refers to a SCM repo, the server SW loads the sources and zips a meta-package. Clients can use that package directly.
Server side SW is needed obviously.

Juha

I read it wrongly,No I dont like getting directly because of many reasons like their services limit and the soul of "no force dependency on others" of FPC and Lazarus.

I think we are the same page.

Its good to have a server that get around packages together from supported sources and so on.
There is one tiny problem that keep packages uptodate, we can sync as package maintainer update it in a client tools or we can sync it in a cycle . not decided yet.

Regards,
Ara

Aradeonas wrote

The most important part is it make easy to use packages and sharing them so increase the power of community and get more attention on each other work and attract new users to this brilliant space ;)

Yes but let's leave the spirit elevation speeches and do some code. :) Well, I can promise to do code myself only after a month or so. I have other activities and the weather is good etc.
I will hopefully get a new computer within a month, too. Now using a mini-laptop.
Yet I promise to read and write mails.

I'm researching about all same services ,next make plan and structure after reading exist codes and then invite every people that want work on some part of this if they want.

I can see you are new to open source. "Inviting every people to work" does not work. You must create some working code first yourself and then others _may_ join but it is not sure even then. If you study the existing package manager systems too much, you will be very confused.
The tools may have advanced server SW, Python, JS, web user interfaces etc. KISS.

For now I'm interested in community opinions so keep them in mind while the researching and planning.

Don't count on community opinions too much either. Everybody has lots of opinions but very few people are willing to implement them. It is so easy to suggest something "advanced" as long as somebody else implements it.
The person who actually implements things has more voting power. That's how it must be.

Juha

Yes but let's leave the spirit elevation speeches and do some code.

Im working on it before making topic but as many others here Im also busy with some projects but the difference is I like it and Im working on it no matter what ;)

Well, I can promise to do code myself only after a month or so. I have

other activities and the weather is good etc. You want to work on this?if yes what parts do you like so I save it for you.I have problem with IDE ingerations becuase I dont know much about it.

I can see you are new to open source.

Yes but what Im saying is just a testing and I know from past I should make it my self.

invite every people that want work on some part of this if they want

I said if they want and probably no one want but it worth to know ;)

Don't count on community opinions too much either. Everybody has lots

of opinions but very few people are willing to implement them. It is so easy to suggest something "advanced" as long as somebody else implements it. The person who actually implements things has more voting power. That's how it must be. As I said I know from past I should make it my self but I always like hearing others opinion, and if any one want to help so make a tam on that.

Regards, Ara

Aradeonas wrote

There is one tiny problem that keep packages uptodate, we can sync as package maintainer update it in a client tools or we can sync it in a cycle . not decided yet.

Supporting package update from the client tools would require user authentication and server side SW etc.
At least initially it must be done by admins who have direct access to the server.
It means that authors can host their packages somewhere else and then provide patches for the package list in our server, listing the URL for their server.

Juha

Why not ? fppkg just needs a zip file, and expects a fpmake.pp.

The fpmake.pp is easily translatable to lazarus package and vice versa.

If additional functionalities are needed, we can add whatever is necessary.

I hope so :)

The fpmake related stuff and the package format cannot be reused.

See above, why not ?

Also the client must be a Lazarus IDE package with a nice GUI instead of a cmd line program.

fpmake was designed to have a GUI from day 1.
It was thought through, you know :)

All that fpmake does is register some units and then start the builder/installer. A descendent of the builder/installer can be created to start a GUI.

If someone needs an explanation of how this is done, I can provide whatever is needed.

As for repositories: I have no problem letting the initial/master repositories be hosted on the FPC server. Any package can be uploaded, dependencies are not an issue.

The only thing I ask is that if a web-interface is made, and it needs a database, it depends only on postgres or firebird. No mysql. Preferably the backend of the web interface is made with FPC, but any other technology is fine (PHP being at the bottom of the list because I consider it a security leak).

Michael.

"Juha Manninen" wrote

On Mon, Aug 10, 2015 at 8:52 AM, Aradeonas

The SCM allows to retrieve older versions like tags or even specific revisions.

In fact, allows to have multiplex versions without the burden of hav? to upload every time a new version is released.

About using SCM to something that does not need: really it does not need but would make the feature more flexible and easier to maintain (think of the server maintanance and how a shutdown would affect the Lazarus users).

Luiz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150810/e40c7bb3/attachment.html>

If someone needs an explanation of how this is done, I can provide whatever is needed.

Ok,I really want to hear from you about this.

The only thing I ask is that if a web-interface is made, and it needs a database,

it depends only on postgres or firebird. No mysql. Preferably the backend of the web interface is made with FPC, but any other technology is fine (PHP being at the bottom of the list because I consider it a security leak).

Firebird can be good choice?although?it been years I didnt work with it but?No problem,happy to work with it again. About backend I will insist on a FPC backend ,when our language work well why use another? ;)

Regards, Ara

Very nice idea!

I use something like this in other languages and it is very useful (NPM, Gradle, Maven, APT, Yum etc). The NPM project uses a nice approach: "keep your project in your repository (Github, Bitbucket etc) that we will publish it as-is", see an example: https://www.npmjs.com/package/express (although you found Express in NPM, this package is hosted in Github https://github.com/strongloop/express).

So you can install a new package localy in your project just performing "npm install some-packe" (even a new project, "npm install new-project", and you can start it too, "npm start"), or global, performing "npm install some-package -g", and to init a new "packages.json", just perform "npm init". In Lazarus, the local installation could be in the project's folder, and the global installations could be done in the "lazarus/components" folder, eg: "lpm install -g synapse", or "lpm install some-project-or-package-hosted-in-github --save" (--save saves all sources of you package). =)

Some times ago I saw a online package in CodeTyphon project too, but I don't remember how it does that, but you can take a look on it. =)

Michael Van Canneyt wrote

Why not ? fppkg just needs a zip file, and expects a fpmake.pp. The fpmake.pp is easily translatable to lazarus package and vice versa.

Now I have a gap in my knowledge.
I thought that fpmake is a replacement for "make", not for Lazarus packages. I want to understand this topic better.

Juha

Juha Manninen wrote

I want to understand this topic better.

fppkg and fpmake works together. fpmake can generate a zip archive and a manifest file for use with fppkg server.

Take a look at fpGUI's fpmake.pas unit.

$ cd <fpgui>/src/
$ fpc fpmake.pas
$ fpmake --help
Usage: ./fpmake command [options]
Where command is one of the following:
compile Compile all units in the package(s).
build Build all units in the package(s).
install Install all units in the package(s).
clean Clean (remove) all units in the package(s). archive Create archive (zip) with all units in the package(s). manifest Create a manifest suitable for import in repository. ...snip...

$ ./fpmake archive --prefix=fpgui/
(you now have a fpgui-1.5.zip archive created
$ ./fpmake manifest
(you now have a manifest.xml file created - ready to submit to fppkg)

The only problem I have seen thus far is fpmake is hard-coded to look for fpmake.pp, and my file is name fpmake.pas - I get this error because of it. Simply rename it to .pp and the above works fine.

$ ./fpmake archive --prefix=fpgui/
The installer encountered the following error:
File "fpmake.pp" does not exist.

Regards,
- Graeme -

Juha Manninen wrote

Phase 3 : Support user rating and comments for packages.

Phase 4:
Build a "online store" where ISV's can sell their packages, and accept Google Wallet, PayPal or BitCoin payments. ;-)

Regards,
- Graeme -

It is both.

Sources are divided in packages.
A package is defined as a set of units that are built together.

fpmake does 2 things:
- It enumerates the units that make up the package.
- It has some metadata: author, version, description.
- It provides exact build instructions for the units.
- As part of the build instructions, dependencies between packages but also between units can (and must) be specified.

As you can see, this is the equivalent of a lazarus package, and even a little better since lazarus (currently) does not manage dependencies between units.

fpmake can also
- Compile the units/programs
- Create a manifest file (this is the equivalent of a package file, it's also XML)
- Create a source zip
- Onstall the units where the compiler can find them (this would not be needed for lazarus packages)
- Create the documentation.
- I have an extension (uncommitted) where it also can compile and run a testsuite.

This is currently the domain of the lazarus IDE or lazbuild.

So,

one possible working scheme that was originally though of:
- use fpmake/fppkg as package format
- Inside lazarus, let fpmake generate a lazarus package (should be a no-brainer)
- Lazarus loads/compiles the generated package
Another possible working scheme is:
- use fpmake/fppkg as package format
- Lazarus packager detects fpmake and calls it to compile everything as well as generate a lazarus package.
- Lazarus loads the generated package

A third (but very improbable, I suspect ;) ) possibility is that lazarus switches building of packages to fppkg. It was designed to make this possible.

Probably there are some variations possible.

Michael.

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

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.

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.

Michael Van Canneyt wrote

> 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.

Already possible/supported. I've been doing something similar for years. I have a unit path specified in my ~/.fpc.cfg. If I copy say my custom version of the fpcunit.pp in there, whenever I compile the Lazarus GUI Test Runner (or console runner), FPC uses my version, and not the one included in FCL.

eg: Add the following at the beginning of your ~/.fpc.cfg file.

# apply custom fixes
-Fu/data/devel/myfixes/

I learned this tick from my years with Delphi 7 and Kylix 3.

> 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.

+1

Regards,
- Graeme -

An online repository is potentially vulnerable to:

- DoS Attacks
- Man in the middle attacks
- Unauthorised modification of repository data

DoS is probably out of scope and man in the middle could be countered by demanding https only. However, I don't think I would like to claim that any website is invulnerable to unauthorised modification. Hence why I propose that a digital signature is available for each file in the repository. The basic idea is that the signing key is only available to an authorised user (probably 3DES encrypted) and thus even if an attacker succeeds in uploading a malicious file, the attack is not unsuccessful unless the attacker can persuade the site administrator to sign the file.

This extra level of security should be sufficient to counter such an attack.

Tony

Michael Van Canneyt wrote

- As part of the build instructions, dependencies between packages but also between units can (and must) be specified.

Why is that?
Unit dependencies are already specified in uses sections of the units themselves.

I will study the fpmake / fppkg stuff more soon ...

Juha

Because then you can optimize the compilation process. If units are specified in the "wrong" order, they can be processed twice.

Michael.

Juha Manninen wrote

Unit dependencies are already specified in uses sections of the units themselves.

In the case of fpGUI I couldn't create a single fpgui_toolkit.lpk package that fully supports fpGUI, because depending on the platform, it has different unit paths, and in some of those paths there are units with the same name (which acts as a bridge between the backend and front-end). A similar thing for include files used in the implementation section of some units. So due to the limitations of Lazarus Packages, I had to create two sets of fpgui_toolkit.lpk packages - one in the "x11" directory, and one in the "gdi" directory. A real pain in my side. If I start supporting other backends, then the package count would increase even more.

With fpmake, it has sufficient flexibility so I only need a single fpmake.pp no matter the platform or graphics backend.

Incidently, due to the above mentioned limitations (and a few other gripes), I'm moving more and more away from Lazarus Packages and rather to a Macro based setup.

Unfortunately none of the IDE's I use currently support fpmake, so I haven't used it much. But for console based compiling, it works very well.

Regards,
- Graeme -

Incidentally:
This is why we opted to make the "package format" fpmake.pp a pascal file. It avoids heaps of tags, attributes, scripting additions or whatnot: It allows for unlimited flexibility and every person making a package already knows Pascal.

Michael.

Michael Van Canneyt wrote

This is why we opted to make the "package format" fpmake.pp a pascal file.

A very wise move. :)

I guess fpmake.pp is exactly the same thing... I often write small console tools to accomplish some tasks, because I can't bother the learn the various *nix shell scripts and Windows batch file syntax. A single Object Pascal console utility works everywhere.

Regards,
- Graeme -

That is also the philosophy beyond instantfpc.

Michael.