Skip to content

Thoughts on the FreeBSD ports/package system #161

@probonopd

Description

@probonopd

While we have been working with FreeBSD packages for a while, it seems like the structure of how packages get built and distributed leaves a few aspects to be deserved. This issue describes our gripes in the hope that someone can help us find solutions.

  • The FreeBSD base system and packages should feel like one consistent system, not like a "split personality". They should be upgraded together, e.g., when one upgrades the FreeBSD base system from 12.1 to 12.2 then all packages that require different binaries to work on 12.1 vs. 12.2 should be upgraded as well (e.g, Intel GPU driver). If the Intel GPU driver that is available in packages does not work with the base system, then this should be a blocker preventing the base system from being released. (In fact I think that Xorg and all GPU drivers should become an optional part of the base system because they are as essential to the operation of a graphical system as the kernel and basic command line userland.)
  • This also means that for FreeBSD -RELEASE the packages should be equally "slow-changing" (not rolling release!), whereas for -CURRENT rolling release is acceptable
  • It should be possible to use quarterly packages without the fear that from one day to the next a package disappears (it is ok if the old version of the package stays around until a new one is produced, but packages just going missing is not acceptable). In fact, isn't "quarterly" supposed to not change during the quarter? Users who want daily changing packages can use latest. This could be achieved by freezing a snapshot of latest at the begin of each quarter, and only allow new packages to be added after this point but not to change existing packages except for very urgent security patches
  • As long as the point before is not solved, we are forced to use release_X packages (which get frozen at the time when the FreeBSD images are built). But there is no way to get new packages into release_X packages which effectively means that we can get new packages only after a quarter has passed (e.g., falkon-qtonly is not available in http://pkg.freebsd.org/FreeBSD:12:amd64/release_2/ but hopefully will be in release_3)
  • We need to find a way to tell pkg not to touch/overwrite certain files (example: files in /usr/local/share/dbus-1/services/, details)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions