Context Navigation

Migration

Timestamp:: Oct 3, 2013, 6:06:44 PM (11 years ago)
Author:: bonefish
Comment:: Add item regarding the modified stage 1 boot loader and makebootable.

Legend:

: Unmodified
: Added
: Removed
: Modified

Obsolete/MovedToTree/PackageManagement/Migration

-              v4
+              v5
  * The Deskbar menu works differently. It uses a new virtual directory Tracker/Deskbar feature to generate its content. Any package can contribute Deskbar menu entries by including respective symlinks in "data/deskbar/menu". The virtual directory merges the respective directories from all installation locations plus the user settings directory "/boot/home/config/settings/deskbar/menu". That means whenever a package is installed/removed its Desbar menu entries will be added/removed automatically. The user settings directory allows the user to add new entries manually. The whole behavior can be changed by overriding the default virtual directory. Before using the default virtual directory "/boot/system/data/deskbar/menu_entries" Deskbar first looks for "/boot/home/config/settings/deskbar/menu_entries". This can be a virtual directory as well, or a regular directory, or a symlink to either. E.g. making it a symlink to the "menu" directory will cause Deskbar to use only the contents of that directory, i.e. the menu contents is completely user-defined.
  * The MIME type management works a bit differently now as well. The database entries for the default MIME types are included in the system package and those for application MIME types are included in the package containing the respective applications. Neither of those can therefore be removed. By editing them in the FileTypes preferences application they can be overridden, though. ATM there are still a few known bugs and missing features -- e.g. application MIME types aren't automatically added/removed when installing/removing a package, and the MIME type removal functionality in FileTypes needs to be reworked.
+ * Haiku's stage 1 boot loader (the boot block in the BFS partition) has changed. That means a Haiku partition made bootable from an old Haiku -- or more generally: with a `makebootable` that predates package management -- will not be able to boot a package management Haiku. You will have to run the new `makebootable` to make it bootable again. The new `makebootable` may or may not run on an old Haiku. The safest way is to do that from a running package management Haiku (e.g. booted off a USB stick or CD).
 …
    * `--build-cross-tools` and `--build-cross-tools-gcc4` have been merged. The (packaging) architecture must always be specified.
    * `--build-cross-tools` and `--cross-tools-prefix` can be given multiple times to specify hybrid builds. Only for the first `--build-cross-tools` the path to the build tools must be given.
  For example, for building the default configuration of Haiku from a file system with propery xattr support, your configure options could look like this:[[br]]
+ For example, for building the default configuration of Haiku from a file system with proper xattr support, your configure options could look like this:[[br]]
  {{{$ ./configure --build-cross-tools x86_gcc2 ../buildtools --build-cross-tools x86 --use-xattr}}}
    * The new option `--target-arch` has been introduced for use on Haiku for builds with the native compiler. By default, if neither `--build-cross-tools` nor `--cross-tools-prefix` are specified the build is configured for a (hybrid) configuration matching the host system's (i.e. on a gcc2/gcc4 hybrid the build is configure for that configuration as well, on a pure gcc4 Haiku you'd get a gcc4 build). `--target-arch` overrides the default, allowing to specify the architecture to build for. The option can be given multiple times to specify a hybrid configuration. E.g. "--target-arch x86_gcc2 --target-arch x86" specifies a gcc2/gcc4 hybrid and can be used on a gcc2/gcc4 or gcc4/gcc2 Haiku.