Nope, that one is very useful for those who don't want FPC managed by package manager (at least I'm in the list). It's also the one provided in sourceforge.
Thats ever lasting problem with both FPC and Lazarus that they are forcing users often to recompile tools itself. This can be useful for its developers but not for users who need to use Lazarus as working tool and focus on their project. I spend significant more time on fixing and debugging Lazarus while no such activity is necessary to use commercial Delphi IDE. So to have simply installable platform native packages are basic requirement of any project which wanted to be successful.
Not really:
$ make help
Targets
all Build a new compiler and all packages
install Install newly build files
zipinstall Create zip/tar of installed files
singlezipinstall Alias for zipinstall
Just try to run make zipinstall on Linux and it will produce .tar.gz. Thats all story. So feature should be named archive_install or whatever more general name.
Both are independent projects anyway.
That have many bad consequences. Lets imagine that Delphi compiler and Delphi IDE would be created by two different companies. Fortunately this is not the case. But for example Lazarus packages and FPC packages are clear example that current state is far from perfect.
Perhaps that's a requirement from Debian sponsor who uploads the package, who knows? The RPM package is not splitted that way, though, nor is the Arch Linux package.
Sure, I am aware of that, but this wont change that this is bad. At least FPC team could provide correct deb packages on their web site or provide apt repo list as for example Jenkins does.
No other IDE I know provides such a broad range of installer creation option. It's even impossible to build certain format under different system other than it's intended for (unless someone is crazy enough to reimplement all of them without their official tools which often only runs on a specific system). If you really want to implement this, I suggest to extend LazPackager instead of starting from scratch.
Sure, it could be implemented as runtime package. I don't know how complicated it would be to implement such feature into Lazarus. If is there any API documentation for developing runtime packages or just code is documentation.
Also there is a problem that what developer of an application would need is to be able to generate all install binaries for all selected platforms at once. Which would require to support cross-compilation and automated rebuild of project multiple-times for several targets. This is not possible now or at least too hard to setup for ordinal developer.
To go back to original topic. There are several problems with automated build system. For example pairing multiple combinations of Lazarus and FPC versions. Each Lazarus version is expected to be build on some FPC version and packed with different newer FPC version. I don't know if this is recorded somewhere. Also one FPC version need to be build with previous version. And all these working FPC instances need to be available on build server.
I tested create_lazarus_deb.sh script and it generated deb package as expected. But for optimization point of view it rebuilds entire Lazarus on each call. So for daily build to save CPU load it would need to be optimized to do build just once to generate for example RPM and DEB.
Entire process of building need to be optimized to take as low space and time as possible. For example problem with SVN is that it stores second copy of all files in .svn subdirectory a pristine copy. Which gets significant problem if build server as Jenkins try to download code for each job and subjob. Not mentioning wasteful checkouting from main SVN server. This needs to be improved definitely. Just "svn export" itself will not allow Jenkins to detect if new commit was done and build need to be rerun.