The package kit actually requires the files "repo", "repo.info",
"repo.sha256" to be located under the repository base URL, so the
approach to name the repository file "repo-<hash>" doesn't work.
Now there's a directory "<hash>" which contains the files.
This commit moves the computation of the hash and downloading the
repository file from the build_haiku_image script to the jam build
system. The repo.info is also downloaded and a repository config file
is generated.
* 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.
* Deskbar now uses ~/config/settings/deskbar/menu_entries for its menu,
falling back to /system/data/deskbar/menu_entries, when the former
doesn't exist. The latter always exists and is a virtual directory
merging the deskbar/menu subdirectories of ~/config/settings/ and
<any installation location>/data/. So, if a package provides a
deskbar menu symlink, it is added automatically when the package is
activated. The user can add own menu items by putting stuff into
~/config/settings/deskbar/menu/, only use their own organization by
symlinking it to menu_entries, or do fun stuff by making menu_entries
a customized virtual directory.
* HaikuImage: No longer create any deskbar menu symlinks in the user's
settings directory. Instead add them to the Haiku package.
* OptionalPackages: At least for the optional packages that do have
hpkgs, no longer create deskbar menu symlinks in the user's settings
directory.
* Move all Deskbar settings files to ~/config/settings/deskbar/ and
drop the "Deskbar_" prefix.
* Also make use of new build feature rules.
* Since the hacky long_jump_buffer field has been removed from the
jpeg_error_mgr struct in the new package, the structure is now
wrapped in the JPEGTranslator code to achieve the same behavior.
* Add new package haiku_loader.hpkg and move haiku_loader there. The
package is built without compression, so that the stage 1 boot loader
has a chance of loading it.
* Adjust the stage 1 boot loader to load the haiku_loader package and
relocate the boot loader code accordingly.
* add vesa.accelerant, vesa driver, ps2, isa, bios, generic_x86 for x86_64 too
* only have reiserfs, firewire, agp_gart targets for x86
* reverted hrev43950, liblocale alias shouldn't be needed anymore
* Add optional packages Zlib and Zlib-devel.
* Simplify the build feature section for zlib and also extract the
source package.
* Replace all remaining references to the zlib instance in the tree and
remove it.
It points to the settings directory appropriate for global settings.
When a package is installed in ~/config, we cannot use the settings/
subdirectory for global settings, since then the files could clash with
equally named user specific settings files (e.g. in case of
ssh/known_hosts). So we use ~/config/settings/global for global
settings instead.
Apparently it isn't ready yet. I haven't found a single syslog on Trac
that shows a successful initialization of the driver, and on my
machine, where it does that at least, the system freezes during boot.
* 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.
* Tried to use EFI::Header class, but there doesn't seem to be an easy
way to actually hit the disk -- which we'll have to do to find out
how large the GPT table is.
* Initialization of GPT disks is now working which is why I added the disk
system add-on to the image. However, there is a caveat, as the backup
header and table aren't written yet.
* Partitions can be deleted.
* Creating partitions does not work yet, but I don't know yet why; in
theory it could already work.
..and Haiku64Image. While I'm at it split the commands so each letter
in the alphabet gets it's own line(s). This will make these kinds of
changes more atomic in the future.
Work I did at Begeistert, trying to use the new driver manager and
detecting display controls. It should probably be a good example of
how a new driver is built. It currently loads and detects
display controls correctly but doesn't do any actual work yet.
Not sure when I have the time to finish the driver, it shouldn't be
that hard but I currently have have other priorities. Feel free to
work on it in the meantime.
Got rid of X86_ONLY and friends in HaikuImage, FloppyBootImage, etc.
Instead we use build feature specification annotated lists with
FFilterByBuildFeatures (either explicitly or implicitly where passing
the list directly to the image rules).
I just translated the variables to the respective annotatation in most
cases, though in some cases different annotation would be more correct
(e.g. for the OpenGL stuff).
Provides a simple framework for addressing #3798. The interested reader
may add the build features and add/adjust the annotations accordingly.
