#
ca7a630e |
|
03-Jan-2019 |
Alexander von Gluck IV <kallisti5@unixzen.com> |
kits/package: Break LibsolvSolver add-on out * BSolver is implemented by solver add-ons * We may want to (unlikely) leverage another package solver in the future. * We may want to (likely) implement a dummy solver when libsolv is unavailable on new architectures without bootstrap. * This also makes solving missing libsolv a little more graceful vs the "include "libsolv.h" not found. Change-Id: Iedd9d0f022fb743c4c7606bd33a4b6dbef0576f7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/819 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
cf0ba058 |
|
06-Feb-2017 |
Humdinger <humdingerb@gmail.com> |
Add localization to package daemon and solver Thanks to Adrien and Rene for reviewing and guidance. Fixes #13282.
|
#
220d0402 |
|
31-Jul-2014 |
Oliver Tappe <zooey@hirschkaefer.de> |
Use libstdc++, libsupc++ and libgcc from gcc_syslibs. * Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so from the gcc_syslibs build feature for everything except x86_gcc2. * Use libgcc_s.so from the gcc_syslibs build feature for everything but x86_gcc2 (which still carries libgcc as part of libroot.so). * Drop filtering of libgcc objects for libroot, as that is no longer necessary since we're only using libgcc-as-single-object for libroot with x86_gcc2, where the filtered object file doesn't exist. Should the objects that used to be filtered cause any problems as part of libgcc_s.so, we can always filter them as part of the gcc build. * Use libsupc++.so from the gcc_syslibs build feature for everything but x86_gcc2. * Adjust all Jamfiles accordingly. * Deactivate building of faked libstdc++.so for non-x86-gcc2. For x86_gcc2, we still build libstdc++.so from the sources in the Haiku source tree as part of the Haiku build . * Put gcc_syslibs package onto the image, when needed.
|
#
c591ff14 |
|
05-Aug-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Support building libpackage-add-on-libsolv.so for secondary arch
|
#
a20eb7f4 |
|
13-Jun-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Update libsolv package Also make use of new build feature rules.
|
#
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.
|
#
220d04022750f40f8bac8f01fa551211e28d04f2 |
|
31-Jul-2014 |
Oliver Tappe <zooey@hirschkaefer.de> |
Use libstdc++, libsupc++ and libgcc from gcc_syslibs. * Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so from the gcc_syslibs build feature for everything except x86_gcc2. * Use libgcc_s.so from the gcc_syslibs build feature for everything but x86_gcc2 (which still carries libgcc as part of libroot.so). * Drop filtering of libgcc objects for libroot, as that is no longer necessary since we're only using libgcc-as-single-object for libroot with x86_gcc2, where the filtered object file doesn't exist. Should the objects that used to be filtered cause any problems as part of libgcc_s.so, we can always filter them as part of the gcc build. * Use libsupc++.so from the gcc_syslibs build feature for everything but x86_gcc2. * Adjust all Jamfiles accordingly. * Deactivate building of faked libstdc++.so for non-x86-gcc2. For x86_gcc2, we still build libstdc++.so from the sources in the Haiku source tree as part of the Haiku build . * Put gcc_syslibs package onto the image, when needed.
|
#
c591ff14a109d9af2497fcd50886aa867391374c |
|
05-Aug-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Support building libpackage-add-on-libsolv.so for secondary arch
|
#
a20eb7f497fd5789baee973d9f381d155c231951 |
|
13-Jun-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Update libsolv package Also make use of new build feature rules.
|
#
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.
|