Context Navigation

Migration

Timestamp:: Nov 23, 2013, 10:27:22 PM (11 years ago)
Author:: bonefish
Comment:: /boot/common removed. Mention setarch and find_path*(). Update on update-packages.

Legend:

: Unmodified
: Added
: Removed
: Modified

Obsolete/MovedToTree/PackageManagement/Migration

-              v5
+              v6
  * Almost all software lives in packages and is only virtually extracted. The virtually extracted package content is read-only.
  * Software (i.e. packages) can be installed via the command line package manager `pkgman` -- `pkgman search/install/uninstall/update ...` searches for, installs, uninstalls, and updates packages respectively. Packages can also be installed manually by moving (not copying) them to the respective "packages" subdirectory in "/boot/system", "/boot/common", or "/boot/home/config".
+ * Software (i.e. packages) can be installed via the command line package manager `pkgman` -- `pkgman search/install/uninstall/update ...` searches for, installs, uninstalls, and updates packages respectively. Packages can also be installed manually by moving (not copying) them to the respective "packages" subdirectory in "/boot/system" or "/boot/home/config".
  * The directory layout has changed and many directories have become read-only. Cf. [wiki:PackageManagement/DirectoryStructure DirectoryStructure] for details.
  * 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.
 …
  * All development files (headers, libraries, the tool chain) have moved to "develop" in the respective installation location. Headers live in "develop/headers", development libraries in "develop/lib". Development libraries means besides static libraries also symlinks to shared libraries. The shared libraries themselves as well as all symlinks required to run a program using the library (at most one symlink per library -- the soname) live in "lib".
  * Commands, libraries, add-ons, and headers for the secondary architecture of a hybrid Haiku live in an "<arch>" subdirectory of their usual location. This doesn't hold for the system headers which exist only in the primary location.
  * `setgcc` is gone. The commands of the tool chain for the secondary architecture live in "/boot/common/bin/<arch>". Prepending that path to the `PATH` environment variable would make them shadow the respective primary architecture commands -- the effect would be similar to the one `setgcc` had, but only for the current shell session. The commands of the secondary tool chain are also available in the standard path with a name suffixed with "-<arch>" (e.g. "gcc-x86" for the gcc 4 executable on a gcc2/gcc4 hybrid).
+ * `setgcc` is gone. The commands of the tool chain for the secondary architecture (by default) live in "/boot/system/bin/<arch>". Prepending that path to the `PATH` environment variable would make them shadow the respective primary architecture commands -- the effect would be similar to the one `setgcc` had, but only for the current shell session. Executing the new command `setarch <arch>` will start a new shell with a respectively modified `PATH`. The commands of the secondary tool chain are also available in the standard path with a name suffixed with "-<arch>" (e.g. "gcc-x86" for the gcc 4 executable on a gcc2/gcc4 hybrid).
  * Software can be packaged using the `package` tool. Cf. [wiki:PackageManagement/BuildingPackages BuildingPackages] for more information.
+ * The `find_directory()` API has been partially deprecated. While there are still some use cases where it should be used, in many cases the new `find_path*()` API, respectively the `BPathFinder` class should be used instead (cf. the [http://api.haiku-os.org/FindDirectory_8h.html API documentation]).
 …
  * Build features (as defined in "build/jam/BuildFeatures") work differently now. Instead of build variables there are dedicated rules to deal with build features (FIsBuildFeatureEnabled, UseBuildFeatureHeaders, BuildFeatureAttribute). Cf. [https://github.com/haiku/HaikuPM/blob/package-management/src/add-ons/mail_daemon/inbound_protocols/pop3/Jamfile src/add-ons/mail_daemon/inbound_protocols/pop3/Jamfile] for an example.
  * The semantics of the "update" build profile action has changed somewhat, since due to the packages we now have two container levels, the image and the package. A `jam -q @alpha-raw update libbe.so` will first update libbe.so in the haiku.hpkg package and then update haiku.hpkg in the image. A `jam -q @alpha-raw update haiku.hpkg` will update "haiku.hpkg" in the image, but "haiku.hpkg" will not be rebuilt. If that is desired, it first has to be rebuilt explicitly -- via `jam -q haiku.hpkg`. Note that this might be problematic as well, since which optional build features are active depends on the specified build profile.
  * There's a new build profile action "update-packages". It updates all packages and then updates all packages in the image (including downloaded ones). It's a poor man's system update. Since it just copies the packages to the image, potentially replacing equally named packages, older packages with a different name will not be removed. Due to the system remembering which packages are active, it is recommended to empty the "/boot/{system,common}/packages" directories first (also removing the "administrative" subdirectory).
+ * There's a new build profile action "update-packages". It updates all packages, empties "/boot/system/packages" in the image, and copies the updated packages there. It's a poor man's system update. Packages you have installed manually will be removed. The old "update-all" build profile action still exits. It has the effect of "update-packages" and additionally replaces all other files that are usually copied to the image.