* Rename TransactionHandler -> InstallationInterface and
DaemonClientTransactionHandler -> ClientInstallationInterface.
* Add InstallationInterface::InitInstalledRepository(). Use in
_AddInstalledRepository() to get the repository packages instead of
using the package roster. The ClientInstallationInterface
implementation does it that way.
* adding zlib to the kernel unfortunately introduces a cyclic dependency
with respect to the zlib, haiku and haiku_devel packages (AFAICS)
* circumvent this by building kernel_zlib as a static library again,
this time with PIC, such that it can be used by kernel add-ons
* Move RepositoryBuilder class to libpackage and add B* prefix to name.
* Pull BPackageManager class out of PackageManager and move to
libpackage. The base class is customizable via three handler objects
responsible for transaction handling, request execution, respectively
user interaction.
* Reorganize _ApplyPackageChanges(): Now we first prepare the
transactions for all affected installation locations (downloading
files etc.) and then commit them.
The property is archived and unarchived, but otherwise not yet stored.
If not set, FileName() returns CanonicalFileName(). Can be used for
packages like haiku.hpkg etc. that don't have a properly qualified file
name (yet).
... after having determined the packages to remove from the selected
installation location. This uninstalls packages from the more specific
locations when their dependencies have been removed.
We update/set it in _AddRepositories() instead of in AddRepository(). In
code needing it earlier _InstalledRepository() can be used.
This change allows calling to SetInstalled() on a repository that has
already been added to the solver.
* I have no idea why, but gcc2 considers BSolverRepository* and
PackageManager::InstalledRepository* as distinct pointer types, which
it doesn't like to compare without a cast. Circumvent by static
casting to BSolverRepository*.
* Both filesystems used to link to a static kernel-zlib, which
was being built with -fno-pic. This doesn't work on x86_64 as the
filesystem add-ons are meant to be relocatable, which requires their
code to be compiled as position independent.
Solve that by moving zlib into the kernel, so any add-on can just use
it from there (packagefs is mandatory, so we can't really do without
zlib anyway).
* TARGET_KERNEL_PIC_FLAGS was probably meant to be
TARGET_KERNEL_PIC_CCFLAGS at the time this had been added in 2005.
As correcting the name would mean that kernel add-ons would be
compiled such that they wouldn't be position independent, dropping
the variable makes more sense (which is just a cleanup and doesn't
change anything due to that variable being always empty)
... with respect to inter-installation-location dependencies. E.g.
uninstalling a package from common should only uninstall packages
depending on it, when system doesn't still provide those dependencies.
We don't consider uninstalling packages from more specific installation
locations when dependencies are uninstalled from a more general one yet.
Only flag ATM is B_VERIFY_ALLOW_UNINSTALL. It tells to solver to suggest
uninstalling packages when necessary instead of considering such a case
a problem.
If any of the packages to install has requires a base package, that is
installed in a more general installation location, we copy the package
to the target installation location. Ideally we'd hard-link, but BFS
doesn't support that. Symlinks would be a small nightmare to maintain.
We might want to choose the installation location intelligently
depending on the base package requirement -- e.g. install curl_devel in
system rather than common, since curl is installed in system -- so we
can avoid duplicating packages.
It provides the functionality to copy file system entries (also
recursively). The code originates from the copyattr sources. Some
copyattr specific functionality has been removed and the code has been
adjusted for library use (i.e. no exit()s or fprintf()s). An optional
controller object can be set to customize the behavior.
* Remove support for VCSs other than git.
* Make the haiku-revision file a regular build target and make sure it
is built only once.
* Make determine_haiku_revision an actual shell script and simplify
it a bit.
