coapp-developers team mailing list archive

[Mateusz Loskot <mateusz@xxxxxxxxxx>]

Hi,

I am a huge fan of Arch Build System [1] (ABS) which is a ports-like
system for building and packaging software from source code.
It's simple yet powerful, so it even makes it possible to package
existing binaries (e.g. proprietary software). But that's a different story.

I see some similarities between ABS and CoApp.
Both use single package specification file, PKGBUILD [2] or .buildinfo,
which purpose is very similar. Both use a dedicated tool,
makepkg or ptk+autobuild, to generate and pack software binaries.

There is one feature in the ABS which I believe could be interesting for
CoApp and make it simpler to use for package creators and maintainers,
and make the whole process of packaging even more attractive.
Here is part of the features I'm talking about:

PKGBUILD file can specify steps to do the following:
1) download package with sources of released version of a sofware
2) or checkout source from revision control system
3) apply patches, if any required by build process
   (shipped together with PKGBUILD or downloaded too)
4) compile and build binaries


Building a package is as simple as
1) downloading PKGBUILD from Arch User Repository (AUR) [3], or creating one
2) stepping into folder with the PKGBUILD
3) issuing makepkg [4] command (or makepkg -s that will grap and install
    required dependencies automatically, if any missing)

Once a package file (pkgname-pkgver.pkg.tar.xz) is ready, it can be installed
using another Arch Linux command, but that's not relevant here
(on Windows, package is .msi).

In my opinion, the great power of the ABS is that it takes a simple
PKGBUILD file to
perform all steps required by the process of building a package.
No explicit downloading, no forking, no maintenance.
If any changes need to be applied to a packaged software, they are
maintained as patches
(changes to source code) or additional files (e.g. VS solution files,
makefiles, etc.).

An added but fantastic feature of this solution is that it's very easy
to provide
packages for stable release (packaged sources) and for development
version (sources from RCS). So, for users, it's very easy to get, for example,
current development version of software installed system-wide using a single
command, without fiddling with development tools explicitly
(no ./configure or make commands, etc.).

I simply need to install SQLite, a small and very portable library.
I looked at the CoApp package [5] at GitHub and I started to think that it
is an overkill to maintain a fork for such a simple piece of software.
For stable relase of SQLite, the whole maintenance should basically take only:
1) create a makefile or VS project file(s)
2) update version and URL of the source package, after new release

Would such concept fit the philosophy of CoApp?

I haven't monitored the project for several months, so I may be missing the fact
it is already possible. Unfortunately, the manuals are still silent on
the basics.

[1] https://wiki.archlinux.org/index.php/Arch_Build_System
[2] https://wiki.archlinux.org/index.php/PKGBUILD
[3] https://aur.archlinux.org/
[4] https://wiki.archlinux.org/index.php/Makepkg
[5] https://github.com/coapp-packages/sqlite

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net