History log of /haiku/src/kits/package/solver/Solver.cpp
Revision Date Author Comments
# 8bf87f93 30-Sep-2013 François Revol <revol@free.fr>

Actually fix the build

Looks like I was too quick on previous commit.

It seems -pthread is actually not that much needed on Linux though...
although the manpage says "compile and link with -pthread". Go figure.

Now dlopen() uses RTLD_LAZY | RTLD_LOCAL for Linux, which seems
to work here.


# 57405de5 29-Sep-2013 Niels Sascha Reedijk <niels.reedijk@gmail.com>

Always use dlopen and dlsym to load libsolv

Previous implementation used weak symbols on all platforms except Haiku. Mac OS X also does not support this use of weak symbols. In the discussion of #10028 it was decided that probably more platforms will have problems with this approach, so instead use the approach that always works.


# 6eb7e259 28-Sep-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

libpackage_build: undefined weak symbols are unsupported

... also for gcc 4 (#8288), so we have to use the dlopen() method
always when building on Haiku. Fixes the build on gcc 4 Haiku.


# 4dd0ed48 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BSolver: fix for gcc 2

Missed one #if, so sCreateSolver was never initialized.


# bd915d9f 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BSolver: fix build host build for gcc 2

gcc 2 doesn't support the weakref attribute. Rather use the regular
(target) method to initialize sCreateSolver instead (pthread once,
dlopen()). Since we know that we're on Haiku, that doesn't add any
dependencies that aren't available anyway.


# 98c6dfa4 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Switch build system from optional package to repositories

* Build libsolv and the dependency solver part of the package kit for
the build platform.
* Add build tool get_package_dependencies. Given a list of package files
and a list of repository files it determines the additional packages
that need to be retrieved from the repositories and prints their URLs.
* Add rules to work with external repositories in the build system
(build/jam/RepositoryRules):
- PackageRepository declares an external repository with all its
packages. The URL of the repository file isn't specified. It is
computed from a given base URL and the SHA256 hash of the list of
package files.
- GeneratedRepositoryPackageList generates a file containing the file
names of all packages in a repository.
- IsPackageAvailable returns whether a package is available in any
repository.
- PackageURL returns the URL for a package.
* Declare the HaikuPorts repository for x86_gcc2
(build/jam/repositories/HaikuPorts/x86_gcc2).
* Add rule AddHaikuImagePackages to add a package to the image and rule
IsHaikuImagePackageAdded to determine whether a package has been
added.
* OptionalPackages: Remove all entries that just downloaded and
installed an external package. AddHaikuImagePackages can be used
instead and is used in the remaining entries. Also move the remaining
optional package dependency declarations from
OptionalPackageDependencies here.
* ExtractBuildFeatureArchives: Instead of the URL parameter a package
name must be specified now. This allows to simplify BuildFeatures
significantly, since there's no dealing with URLs anymore. "if" out
the entries that aren't supported yet.
* build_haiku_image: For the packages installed in system and common
resolve their dependencies and download and install them as well.


# 1a4d020d 02-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Flesh out the package kit solver API quite a bit more

* Reorganize things a bit:
- BSolver is now an abstract base class.
- A libsolv based implementation, LibsolvSolver, lives in a new
add-on, which is loaded lazily.
- Get rid of libpackage_solver. Save for LibsolvSolver everything
is moved to libpackage.
- This is a nicer solution for the cyclic dependency caused by
libsolv (libsolvext to be precise) using the package kit for
reading repositories and package files.
* Add a solver result data structure and and an accessor the solver.
* Add problem reporting support to the solver. There aren't data
structures for the problem solutions yet and support for selecting
solutions and re-solving is missing as well.


# 479ca816 31-Mar-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Beginnings of the PackageKit dependency solver

Not functional (or tested) yet. The libsolv setup for a somewhat
simplified installation case should be more or less complete, though.
The solution conversion to to-be-created Haiku data structures and the
handling of problems is still missing, though.


# 8bf87f93417aa5ea697a68e409ebea80569bf294 30-Sep-2013 François Revol <revol@free.fr>

Actually fix the build

Looks like I was too quick on previous commit.

It seems -pthread is actually not that much needed on Linux though...
although the manpage says "compile and link with -pthread". Go figure.

Now dlopen() uses RTLD_LAZY | RTLD_LOCAL for Linux, which seems
to work here.


# 57405de578b6ad646e55435b1b1d286cd5a5a6b3 29-Sep-2013 Niels Sascha Reedijk <niels.reedijk@gmail.com>

Always use dlopen and dlsym to load libsolv

Previous implementation used weak symbols on all platforms except Haiku. Mac OS X also does not support this use of weak symbols. In the discussion of #10028 it was decided that probably more platforms will have problems with this approach, so instead use the approach that always works.


# 6eb7e259e9c9dfa1a88cf9cf388c0f3589512531 28-Sep-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

libpackage_build: undefined weak symbols are unsupported

... also for gcc 4 (#8288), so we have to use the dlopen() method
always when building on Haiku. Fixes the build on gcc 4 Haiku.


# 4dd0ed48e3dd486d3f2e8c15eeb90466cd5b0229 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BSolver: fix for gcc 2

Missed one #if, so sCreateSolver was never initialized.


# bd915d9f53216d1998effadf1d8ef25eafdc67a6 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

BSolver: fix build host build for gcc 2

gcc 2 doesn't support the weakref attribute. Rather use the regular
(target) method to initialize sCreateSolver instead (pthread once,
dlopen()). Since we know that we're on Haiku, that doesn't add any
dependencies that aren't available anyway.


# 98c6dfa41e20c57edf426197a8d9aab6223a59fd 05-Jul-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Switch build system from optional package to repositories

* Build libsolv and the dependency solver part of the package kit for
the build platform.
* Add build tool get_package_dependencies. Given a list of package files
and a list of repository files it determines the additional packages
that need to be retrieved from the repositories and prints their URLs.
* Add rules to work with external repositories in the build system
(build/jam/RepositoryRules):
- PackageRepository declares an external repository with all its
packages. The URL of the repository file isn't specified. It is
computed from a given base URL and the SHA256 hash of the list of
package files.
- GeneratedRepositoryPackageList generates a file containing the file
names of all packages in a repository.
- IsPackageAvailable returns whether a package is available in any
repository.
- PackageURL returns the URL for a package.
* Declare the HaikuPorts repository for x86_gcc2
(build/jam/repositories/HaikuPorts/x86_gcc2).
* Add rule AddHaikuImagePackages to add a package to the image and rule
IsHaikuImagePackageAdded to determine whether a package has been
added.
* OptionalPackages: Remove all entries that just downloaded and
installed an external package. AddHaikuImagePackages can be used
instead and is used in the remaining entries. Also move the remaining
optional package dependency declarations from
OptionalPackageDependencies here.
* ExtractBuildFeatureArchives: Instead of the URL parameter a package
name must be specified now. This allows to simplify BuildFeatures
significantly, since there's no dealing with URLs anymore. "if" out
the entries that aren't supported yet.
* build_haiku_image: For the packages installed in system and common
resolve their dependencies and download and install them as well.


# 1a4d020daf80d0b0c30062530cf735ce46dc7dba 02-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Flesh out the package kit solver API quite a bit more

* Reorganize things a bit:
- BSolver is now an abstract base class.
- A libsolv based implementation, LibsolvSolver, lives in a new
add-on, which is loaded lazily.
- Get rid of libpackage_solver. Save for LibsolvSolver everything
is moved to libpackage.
- This is a nicer solution for the cyclic dependency caused by
libsolv (libsolvext to be precise) using the package kit for
reading repositories and package files.
* Add a solver result data structure and and an accessor the solver.
* Add problem reporting support to the solver. There aren't data
structures for the problem solutions yet and support for selecting
solutions and re-solving is missing as well.


# 479ca8169c85621dda097bebe337bcc373eba68f 31-Mar-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Beginnings of the PackageKit dependency solver

Not functional (or tested) yet. The libsolv setup for a somewhat
simplified installation case should be more or less complete, though.
The solution conversion to to-be-created Haiku data structures and the
handling of problems is still missing, though.