Opened 6 years ago

Closed 3 years ago

#10190 closed task (fixed)

Make Bluetooth stack an actual HPKG via build system

Reported by: mmadia Owned by: bonefish
Priority: normal Milestone: Unscheduled
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by mmadia)

By making Bluetooth an actual HPKG, it could be included in the default image as a non-activated package. This would make testing easier for end users.

build/jam/OptionalPackages contains the pre-package management code. build/jam/packages contains several working examples. An accompanying package-info-source will need to be created in src/data/package_infos/

Attachments (1)

0001-Bluetooth-as-HPKG-initial-steps.patch (4.8 KB ) - added by mmadia 6 years ago.
Initial patch

Download all attachments as: .zip

Change History (7)

by mmadia, 6 years ago

Initial patch

comment:1 by mmadia, 6 years ago

Has a Patch: set

comment:2 by mmadia, 6 years ago

Description: modified (diff)

Attached is my attempt to update Bluetooth into a source-built HPKG. Being the first time doing this, I'm uncertain if it's properly done.

This turns the OptionalPackage "Bluetooth" into a HPKG. Currently it is installed to /_packages_. The idea is for the bluetooth package to be installed on the boot medium, without being activated by default.

build/jam/packages/Bluetooth contains a TODO for implementing the development symlink for

Untested beyond being able to build bluetooth.hpkg.

comment:3 by bonefish, 6 years ago

While building separate packages for bluetooth, userlandfs, canna, etc. is the thing to do, I don't think they should be put on the image, unless they are also activated. The intended solution is to have BuildBot (or whatever tool we're going to use) build not only the Haiku image, but also a package repository with all packages produced by the build system, including the optional ones. The user will then be able to install them like any other package, and updates will work as well, when the repository is updated.

Building said package repository is on Oliver's TODO list, but in case he doesn't finish it before his vacation, maybe you want to set this up on your server temporarily. The only thing missing in the build system beside the definition of all the optional packages (mostly for convenience) would be a target or build profile action to create a directory with all the properly named packages.

Regarding your patch:

  • As written above, the package should not be added to the image. There's no need for the optional package section anymore.
  • The package definition looks OK. I suppose the Deskbar entry should go under Preferences, though.
  • The development stuff should probably go in a separate devel package. Since it is not that much, the package can be defined in the same file. The bluetooth headers should be added there as well and excluded from the haiku_devel package.
  • Since there's a library, we'll need a set of packages for the secondary architecture as well.
  • Regarding the package info:
    • The architecture should not be "any". Cf. e.g. the haiku_devel package info for how it should be specified.
    • A more ... uh ... descriptive description would be nice.
    • The "provides" section should include an entry for the library ("lib:libbluetooth = %HAIKU_VERSION%" compat >= ..." (don't know how far, if at all, it is backward compatible)).
    • The "provides" section should include "cmd:..." entries for the command line tools (same versions).
    • The "requires" section should at least include an entry for "haiku". Cf. the package info for haiku_devel, though it probably doesn't need to be marked "base". Don't know, if there are any other requirements.

comment:4 by pulkomandy, 4 years ago

Has a Patch: unset

comment:5 by pulkomandy, 4 years ago

Milestone: R1Unscheduled

comment:6 by waddlesplash, 3 years ago

Resolution: fixed
Status: newclosed

Bluetooth is now just in haiku.hpkg.

Note: See TracTickets for help on using tickets.