App installer design: click packages

[Sergey Shambir]

Hi,

Thanks for efforts on simplifying package management! I'll wait for 
further information from UDS session, but first I want to provide some 
additional info that can help you in research. I'm QtCreator contibutor, 
worked on source code models and project management subsystems, 
including build systems support.

Click packages have many decisions that can scare experienced Linux 
users, but are reasonable. So, for marketing purposes and in order to 
defend idea, please make more detailed overview of each design decision, 
which includes: 1. Comparison of various approaches in this concrete 
problem, with pros and cons. 2. Destroying of common myths associated 
with selected approach (like "if dependencies will be eliminated, size 
of packages will grow significantly").

Possible research agenda:
1. Which benefits brings declarative property-based app manifest?
2. Which benefits brings reversing build system <-> package manager 
interaction order?
3. Can qmake automatically create app manifest in near future?
4. Does size of real applications packages really grow with 
no-dependencies system with SDK (which includes Qt)?
5. Which issues are in Listaller and existing build systems (mostly in 
qmake)?
6. Which pros and cons have installing a) from root b) from user to 
$HOME c) from partially privilegied, but non-root user (similar to 
"wwwrun" or "vboxuser")?
7. Which ways exist to support development model "build on newer system, 
deploy to older"?

Let me throw first stone:

1. Declarative manifest
Main benefit is ability to handle this file automatically: index it, 
provide UI and either generate automatically from build system 
information or parse to get information back. Build systems is an 
excellent example: XCode, Visual Studio and CodeBlocks IDEs have 
property-based build settings, and they can automatically edit such 
settings for years. Meanwhile, no one IDE can automatically edit 
Autotools or Premake files, CMake editing is implemented only in 
KDevelop and is buggy; editing qmake in QtCreator also works wrong in 
complex cases.

2. Reversing build system <-> package manager
Typical project selects one build system, but targets to many platforms. 
At first, when package manager handles buildsystem, user should manually 
debug package manager scripts on each platform. At second, build system 
developers do not want to implement creating packages (because package 
manager designed to handle build system): 
https://bugreports.qt-project.org/browse/QBS-16. At third, this 
situation previously led to ugly design of make-based build systems: 
they are script-based and expose hooks to package manager with 
environment variables or configure options, but have no ability to 
easily use different build configurations (Debug, Release) in same time, 
and portability between platforms achieved with hacks or annoying 
debugging. Declarative build systems have no such problems.

4. Packages size on disk and in memory.
QtCreator in Ubuntu depends on Qt and Botan libraries. It doesn't depend 
on Botan in upstream version, since it keeps Botan copy in sources. Most 
crossplatform apps keep dependencies set as small as possible, because 
Windows and Mac OS X have no dependency-based package system. So, size 
growth will be insignificant.

5a. Listaller issues
Currently Listaller handles build system: 
http://listaller.tenstral.net/docs/doc/packaging.html. Meanwhile, 
buildsystem should handle listaller, and do it easily. No one developer 
wants to manually write and debug list of files to install.

5b. Qmake issues
QMake have INSTALL variable that tracks installable files, but doesn't 
keep target bundle version, description and name. Since QtCreator have 
qmake evaluator, it can be patched to create or update manifest file, 
but some information should be typed by developer.

7. Build on newer system, deploy to older
Listaller and LSB tools from Linux Foundation both use wrappers around 
gcc and special linker wrapper / special version of glibc respectively. 
Another way used in Mac OS X and iOS: XCode contains several SDKs, and 
application builds with only one in sysroot.