Thoughts on the FreeBSD ports/package system

[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)

[crees]

On your third point, this is exactly how quarterly branches work. Breakage is rare and high priority, though I know you were hit by an incident in the past.

For the first point... yes, separation of base and ports is pretty much the number one interesting Thing about FreeBSD. Pkgbase is still very new.

In short, we know about these issues and have been working on them for a while.

[probonopd]

Not sure what is going on here.

% cat /etc/pkg/FreeBSD.conf 
(...)
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
(...)

% sudo pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        firefox: 86.0_2,2 -> 87.0,2

[probonopd]

The FreeBSD base system and packages should feel like one consistent system, not like a "split personality".

This also means that there should be a set of packages e.g., for 12.1 that do not suddenly stop working once 12.2 is released.

I fell into the exact issue here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253452

Even if a FreeBSD minor version is no longer supported, the packages for it should not vanish. Some of us want to set up a system and freeze it in time, sometimes even for decades.

[kettle-7]

So, in other words, what you're saying is that we should have different repositories for different versions, right?

[probonopd]

At least different versions of the packages for different FreeBSD versions for those packages that interact with the kernel directly or are otherwhise dependent on the exact FreeBSD version.

[probonopd]

py37-xdg has been broken in latest packages for FreeBSD 13 on amd64 for quite a while now. This has been breaking our FreeBSD 13 based builds for weeks now.

Turns out that depending on the architecture, the package is now called differently: py38-xdg for amd64 but not for e.g, aarch64. Which both are supposedly "tier 1".

What gives?!?

Suggestions:

• Do not hardcode the Python minor version in the package name, e.g., call it py3-xdg
• Do not have different versions of the same packages depending on architectures

Workaround: Use the pkg install devel/py-xdg nomenclature? (This is a pain, because you have to look up the part before the / for every package.)

[grahamperrin]

py37-xdg … latest …

Please see https://cgit.freebsd.org/ports/tree/UPDATING?id=210ee04dd3c3f2e82cd3130e412866a182066859#n8

[probonopd]

Thanks @grahamperrin. It seems that things are more robust if we use the port names rather than the package names for specifying which packages shall be installed? E.g., pkg install devel/py-xdg will hopefully not break once Python 3.9 is there.

[grahamperrin]

https://github.com/helloSystem/hello/issues/161#issuecomment-846394637

What gives?

Maybe a combination of issues with FreshPorts; see https://github.com/FreshPorts/freshports/issues/287#issuecomment-846322008

---

https://www.freshports.org/devel/py-xdg/#add

To install the port: cd /usr/ports/devel/py-xdg/ && make install clean To add the package: pkg install py37-xdg

root@mowa219-gjp4-8570p:~ # pkg install -n py37-xdg
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'py37-xdg' have been found in the repositories
root@mowa219-gjp4-8570p:~ # git -C /usr/doc pull --ff-only && git -C /usr/ports pull --ff-only && git -C /usr/src pull --ff-only
Already up to date.
Already up to date.
Already up to date.
root@mowa219-gjp4-8570p:~ # cd /usr/ports/devel/py-xdg/
root@mowa219-gjp4-8570p:/usr/ports/devel/py-xdg # make -V FLAVORS
py38 
root@mowa219-gjp4-8570p:/usr/ports/devel/py-xdg # pkg info -x py-xdg
pkg: No package(s) matching py-xdg
root@mowa219-gjp4-8570p:/usr/ports/devel/py-xdg # pkg install -n devel/py-xdg
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed
root@mowa219-gjp4-8570p:/usr/ports/devel/py-xdg # pkg info -x py38-xdg
py38-xdg-0.27
root@mowa219-gjp4-8570p:/usr/ports/devel/py-xdg # 

[probonopd]

Point in case today: https://github.com/helloSystem/hello/issues/203

TL;DR: Installed some applications, which upgraded some system libraries. As a result, was forced to upgrade Firefox. Cannot access meet.jit.si anymore as a result. No obvious way to downgrade.

[grahamperrin]

… upgrade Firefox.

To which version, exactly?

Latest repo, or quarterly?

Which version of helloSystem?

Which version of FreeBSD?

freebsd-version -kru && uname -aKU

Cannot access meet.jit.si anymore as a result.

With recently upgraded firefox-92.0_2,2, the site is accessible:

– and (after clicking Allow) meet.jit.si does recognise the camera and microphone.

https://www.freshports.org/www/firefox/#history there's no more recent version.

No obvious way to downgrade.

Don't forget the boot environment that you created before the upgrade.

If you forgot, then try your cached packages.

[xk2600]

I have often posed the same questions in my head. It feels like there should maybe be an assertion that happens when performing an upgrade but how can the system be aware of where the modules in /boot/modules came from and whether it was a pkg install placed module, ports built module, or compiled from source by the user?

I am personally a huge fan of the pkg and ports system. I believe a lot of the problems with packages/ports getting ousted or breaking stems from lack of developers and maintainers if anything.

My thoughts on sweeping changes... lots of recommendations have been made in the past to overhaul/reorganize the ports system. This would be a pretty complicated endeavor and would probably require a fork of the ports tree. Anything that further segments the BSDs I believe is a disservice to the community. I think there exists enough which can be gleaned from the ports tree to help us make assertions to assist in extending the freebsd-update system. From my perspective, helloSystem is a beautiful distribution of FreeBSD and I would like to see it stay that way. The less we change the more collaboration can exist across both teams on a common code base.

Do not hardcode the Python minor version in the package name, e.g., call it py3-xdg Do not have different versions of the same packages depending on architectures

On the systems that I must support running linux, I have often seen what you are suggesting break in release systems when addition of a module requires updating the interpreter's package. The virtual-environments (as they use symlinks and aren't a copy of the binary) don't protect against this breakage either. My personal opinion is there is too much codependancy on minor versions of python between modules and the binary, especially when modules are backed by C/C++ based libaries. The same goes for perl and tcl/tk, but my guess would be most interpreters suffer the same plight if they allow modules to be backed by C/C++ binaries. My suggestion would be to try and leverage Meta-ports for this mechanism. Discussed below.

So arguments aside, solutions:

• Poudriere-- Build a autoscaling cluster on cloud infrastructure that runs when CI requires it, to host a pkg distribution for helloSystem (if this doesn't already exist). Leverage the FreeBSD ports tree.

• Meta-ports-- Heavily leverage Meta-ports to allow multiple versions of prepackaged modules and interpreters to coexist in the pkg repo. The meta-port points to the latest stable in release and is locked at each minor release of helloSystem. Then if another package has a dependency that doesn't care about the minor version, it can depend on the meta-port. If the meta-port gets repointed to a new version during a minor release cycle, CI can have tests written to notify the build team and automatically changes the dependency for that package to point to the previous minor version. If someone reports a bug for a test that hasn't been written, someone should write a test and update the port to point to the static port major-minor. This should trigger CI to have Poudrier rebuild that package, increasing the pkg database version, so if a user runs into the same problem, a pkg update fixes it.

• Extend the freebsd-update system or build world and include packages in base.tgz-- Right now the pkg/ports system uses the category 'kld' on any port that contains kernel modules. This might be a good mechanism to lookup port/pkgs which should be upgraded with freebsd-update. I haven't dug too far into helloSystem to see how the system gets built yet, but this distribution could effectively be packaged to includes specific Poudriere built packages for graphics to be supported OOTB in base.tgz: drm-next, nvidia, amd, etc.

Anyways just wanted to dig into my thoughts for a moment and get an idea on what others think. I've got a working install, and plan on contributing. What has been done thus far is beyond impressive.

[probonopd]

Thanks for your thoughtful comments @xk2600. As you may have guessed, I am still relatively new to FreeBSD, having spent many years on the Mac and in the Linux universe before. I do see clear advantages in using FreeBSD, and I fully agree that helloSystem should stay a "true FreeBSD", albeit one preconfigured in an opinionated way to work out-of-the-box as a "desktop appliance" (while providing raw FreeBSD power under the hood for those who know what they are doing). For this very reason, I'd like to see those issues to be solved on a FreeBSD level ("for everyone") rather than in helloSystem-specific ways.

Poudriere-- Build a autoscaling cluster on cloud infrastructure that runs when CI requires it, to host a pkg distribution for helloSystem

We are currently not doing this, and I'd like to avoid this for multiple reasons:

• Resources. I simply don't have the resources to build and run such a system. Neither in terms of cost nor in terms of time
• Compatibility. I'd like to keep helloSystem fully compatible with FreeBSD ports and packages should work, as should books and instructions written for FreeBSD. As you are saying, "anything that further segments the BSDs I believe is a disservice to the community"
• Being easy for anyone to fork. By not needing any infrastructure to build helloSystem (other than what GitHub and Cirrus CI provide), anyone can simply fork the repository and create their own modified ISOs. In fact, this is what got me started with helloSystem (by forking the FuryBSD repository), and is what allowed Airyx to have a quick route to an ISO based on helloSystem.

So, right now helloSystem gets built by a shell script from the official FreeBSD binary ingredients plus official FreeBSD ports, at least for the core parts of the system (which for me includes the graphics stack and graphics drivers).

On the subject of graphics drivers, it seems like FreeBSD leadership is aware of the problem and "absolutely need to solve this before FreeBSD 12.3 or 13.1". Your idea to move all "kld" ports to base.tgz or something like it seems reasonable to me - if FreeBSD does it.

[kettle-7]

Maybe while we're trying to figure out a better long term updating option, run the install shell script after pkg upgrade is called?

[kettle-7]

~~or make a new package manager~~

[probonopd]

Making a proof-of-concept Firefox.app

[mszoek]

How can we do this?

I would try using a chrooted package build where the chroot environment is a pristine helloSystem install. That way you will only get packages that are not part of the default system.

[kettle-7]

Again, that gnumeric POC comes to mind, I think that's the way to go here.

[kettle-7]

So basically there's a read-only directory containing a pristine helloSystem copy, that is mounted from an image file, then using unionfs mounts we could get the root filesystem used by the system, with /home, /var, /etc etc. mounted from separate ZFS subvolumes, /tmp mounted tmpfs, and use a similar overlay for apps.

[probonopd]

(Moving the bundle-related topics to #203)

[grahamperrin]

the FreeBSD ports/package system

From Technology Roadmap | FreeBSD Foundation (2021-09-17):

… the pkgbase project is very important, and are ready to help with the effort.

---

https://github.com/helloSystem/hello/issues/161#issuecomment-926129279

graphics drivers

Also from the Roadmap:

– and:

… per-release repositories have been proposed. Release-specific overlays could be used to, e.g., offer DRM packages simultaneously for 13.0 and 13.1 while both point releases are supported. …

[probonopd]

Why does sudo pkg install mtools mess around with LibreOffice? That kind of stuff is driving me insane.

[grahamperrin]

It's impossible to help without relevant details. Kind of stuff.

[probonopd]

Like, which ones?

FreeBSD% uname -v
FreeBSD 12.2-RELEASE r366954 GENERIC 

FreeBSD% cat /etc/pkg/FreeBSD.conf 
# $FreeBSD: releng/12.2/usr.sbin/pkg/FreeBSD.conf.quarterly 346780 2019-04-27 04:00:50Z cperciva $
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

[grahamperrin]

Thanks. Re: the set of questions above https://github.com/helloSystem/hello/issues/161#issuecomment-919581612, which version of helloSystem was it on this occasion? Knowing the origin i.e. which .iso might be relevant.

When was the installation attempted (date and time)?

[probonopd]

My local developer system which has been set up from an experimental ISO (not preserved) in April. Installation was attempted on Sept 15.

[grahamperrin]

Thanks. Did you keep a fuller record of the attempt?

If you refrained from installing: what, now, happens when you remake the attempt?

It's difficult to diagnose things without context but essentially: I don't imagine a problem with FreeBSD pkg in this case.

Bugs do exist e.g. some of what's under https://github.com/freebsd/pkg/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc, however there was probably a good reason for the attention to polish/libreoffice.

[probonopd]

My question was more in general, why would a totally unrelated Polish translation package get updated just because I install some tool. It's not so much about this one instance (which is not really reproducible anyway) but an example of things I don't understand and/or find "complicated" when working with pkg.

[grahamperrin]

https://github.com/helloSystem/hello/issues/161#issuecomment-932960709

FreeBSD% uname -v FreeBSD 12.2-RELEASE r366954 GENERIC

Most remarkable is the outdated OS. At some point you might have ignored an ABI mismatch, and so on.

Next time something seems complicated, please keep a more complete record; some useful context, complete texts (not a screenshot that obscures things of relevance). Thanks.

[probonopd]

12.2 is "outdated"? It's what helloSystem is using due to https://github.com/helloSystem/ISO/issues/198.