FreeBSD binary package versioning/locking

Would you prefer FreeBSD to lock versions of binary packages distributed via pkg for an OS version?

  • Yes

    Votes: 1 11.1%

  • No

    Votes: 8 88.9%
  • Total voters
    9
The version of the OS has nothing to do with the versions in the ports tree. All versions on all architectures use the exact same ports tree. The OS and the ports tree are two separate entities.
 
I added a poll to see if FreeBSD users would actually prefer the way binary packages are versioned on Linux. I think it would make things easier for end-users since you would not have to worry about package versions being updated in upgrades (which might break things (and/or data loss (database upgrade, downtime, etc.)) and may require changing your configuration). This might not be feasible though (in terms of maintaining packages), since Red Hat (which locks package versions for OS versions) for example has to actually backport security fixes when packages are no longer supported upstream (https://access.redhat.com/security/updates/backporting).
 
I'm not too keen with the Linux way of doing this. The way this is handled on FreeBSD provides a few advantages.

For starters it'll make things easier to manage: port maintainers only have to focus on the current FreeBSD release (RELENG 11.0 right now) without worrying about other versions. The second advantage, for end users, is that this way you won't get into situations where the maintainers might be tempted to quit support for stable and CURRENT versions (under the argument that both are basically development releases (as such unstable versions) anyway).

And finally this approach also allows the system to warn people who are using an outdated (End Of Life) version of FreeBSD and urge them to upgrade, instead of quietly accepting whatever the user is doing because the Port version was 'tailor made' for the release they're working with anyway.

(Edit) Fun fact: To my knowledge OpenBSD does work this way. So the version of the Ports collection is directly related to the release you're using.
 
I think whether you would prefer the Linux way (not all Linux distributions follow this but I believe the mainstream ones do) depends on the software that you're deploying and the way you manage your server.

The idea of a package's version being upgraded in an upgrade opens the possibility of the software that I am running being broken during that upgrade. For example, I am using rbenv and ruby-build to build the version of Ruby that I need for my application, but on the system I need various dependencies like gmp, libxslt, etc. If the versions of these packages are upgraded by running pkg upgrade, there's a chance that my build of ruby might be broken, like for example if the ABI for one of these libraries changes. If a package like PostgreSQL goes from version 9.2 to 9.3 in a package upgrade, your data won't be upgraded (I'm assuming that the upgrade process won't attempt to migrate your data for you) which is a disaster. If package versions are locked for OS versions, you would not encounter these issues.

Additionally, without package versions being locked for an OS version, there's no way you can even think of doing unattended upgrades (see https://help.ubuntu.com/lts/serverguide/automatic-updates.html (Ubuntu) and https://access.redhat.com/discussions/1238193 (RHEL)).

If you're just using the base system or only a few packages, package version locking for OS versions might not matter that much.

Code: 
# sh command I currently use to install Ruby build environment
pkg install rbenv ruby-build gmp bash curl libffi libxml2 libxslt libyaml openssl readline sqlite3 wget
echo 'fdescfs /dev/fd         fdescfs         rw,late 0       0' >> /etc/fstab # for bash compatibility
 
Preetpal said:
I added a poll to see if FreeBSD users would actually prefer the way binary packages are versioned on Linux.
Click to expand...
One of the reasons why I genuinely hate the Linux way of doing this is that I don't have a choice anymore. On FreeBSD I can base everything on Apache 2.2 or 2.4, or on PHP 7.0 instead of PHP 5.6, or Ruby 2.3 instead of 2.2, regardless of the version of the OS. I decide which versions to use as default. Which means I can set the same default versions on my 10.3 systems as on my 11.0 systems and vice versa.

Due to the EoL of 9.x I recently upgraded all systems for a client to 10.3. This was really easy to do because everything else stayed the same, the same Apache version, same Ruby, same PHP. So this had zero impact on the applications the client is running.

Additionally, without package versions being locked for an OS version, there's no way you can even think of doing unattended upgrades
Click to expand...
Works just fine here. Just set up your own repositories so you have control of the exact versions. I have repositories for 9.x, 10.x and 11.x. All use the same versions, all set to the same defaults.
 
Hello,
I've been using Debian for years and currently migrating to FreeBSD (because of poetterwares like systemd).

For the few servers I still have under Debian, I need to keep them with Wheezy. And it's a nightmare to backports packages from Jessie to Wheezy.

With FreeBSD, when I migrated from 10.2 to 10.3, I loved having the same ports versions on both versions. Same when I migrated from 10.3 to 11.0. I don't want to manage one different version of each ports for each FreeBSD version.

Regarding the "pinning/locking", there's one port I'm using which I want to keep at an older version. I just use svnlite to fetch the version I want from FreeBSD ports and I compile it with poudriere.
 
SirDice said:
One of the reasons why I genuinely hate the Linux way of doing this is that I don't have a choice anymore. On FreeBSD I can base everything on Apache 2.2 or 2.4, or on PHP 7.0 instead of PHP 5.6, or Ruby 2.3 instead of 2.2, regardless of the version of the OS. I decide which versions to use as default. Which means I can set the same default versions on my 10.3 systems as on my 11.0 systems and vice versa.

Due to the EoL of 9.x I recently upgraded all systems for a client to 10.3. This was really easy to do because everything else stayed the same, the same Apache version, same Ruby, same PHP. So this had zero impact on the applications the client is running.


Works just fine here. Just set up your own repositories so you have control of the exact versions. I have repositories for 9.x, 10.x and 11.x. All use the same versions, all set to the same defaults.
Click to expand...

Honestly I would not like the Linux way of doing this if it prevented me from using the package versions I wanted to use but it doesn't. I only develop Ruby (I manage different Ruby versions using RBENV) and Golang (for which I just deploy binaries). I rarely change (in terms of updating the version of) the other components (PostgreSQL, Nginx, etc.) that my applications web applications interact with. Based on the GitHub issue I referenced (https://github.com/freebsd/pkg/issues/1141), I don't think that all FreeBSD users are aware that binary package versions are NOT locked for a particular OS version which might lead them to be in a situation that they don't want to be in.

I honestly find the way that you described your dependency management to be very awesome though as I didn't really envision that approach. I am relatively new to using FreeBSD and I appreciate the information that I have received so far in this forum.

I am curious though about how you set up your own repository, like do you compile your specific packages (basically using ports) or do you just use pkg (in essence, maybe just using the repository as a staging ground or as a way to control what updates become available to your deployed machines)?
 
Preetpal said:
I honestly find the way that you described your dependency management to be very awesome though as I didn't really envision that approach. I am relatively new to using FreeBSD and I appreciate the information that I have received so far in this forum.

I am curious though about how you set up your own repository, like do you compile your specific packages (basically using ports) or do you just use pkg (in essence, maybe just using the repository as a staging ground or as a way to control what updates become available to your deployed machines)?
Click to expand...
I'm quite fond of ports-mgmt/poudriere, which I've set up for the client. With poudriere it's a fairly simple process, just create a jail for each version of FreeBSD and set up some defaults. Give it a list of ports to build and let it work. Depending on the number of packages to build a few hours later I have, for example, an Apache 2.2 package for 9, 10 and 11. Then it's just a matter of pointing pkg(8) to my own repository and start installing. And because everything to points to my own repositories I have full control over specific versions and default settings. So you get the flexibility of building from ports while keeping the ease of management from using packages.
 
Preetpal said:
That's different than what I've seen on the Linux distributions I've used. They basically lock package versions for the duration of the support cycle of that particular OS version.
Click to expand...

Right, because they have to. Keeping one set of packages locked to one version while upgrading all others is painful, and most distributions either freeze their repositories between releases, or just make everything rolling-release

FreeBSD can be the half-way point and make the packages rolling-release while keeping the base system static, because the base system---the part that is actually FreeBSD---is developed as one complete system by the FreeBSD project. There's no need to freeze the package repositories between versions, because the version of the OS very rarely has any effect on packages, and packages have no effect on the OS.
 
SirDice said:
I'm quite fond of ports-mgmt/poudriere, which I've set up for the client. With poudriere it's a fairly simple process, just create a jail for each version of FreeBSD and set up some defaults. Give it a list of ports to build and let it work. Depending on the number of packages to build a few hours later I have, for example, an Apache 2.2 package for 9, 10 and 11. Then it's just a matter of pointing pkg(8) to my own repository and start installing. And because everything to points to my own repositories I have full control over specific versions and default settings. So you get the flexibility of building from ports while keeping the ease of management from using packages.
Click to expand...
Are you using a separate server for ports-mgmt/poudriere to achieve this? I am asking since I want to use FreeBSD on a server where it really isn't feasible/practical to do builds for packages (768MB ram...). I am mainly wondering if it is possible to use poudriere to do builds on a local machine and then push those locally built packages onto a server.
 
Yes. Checkout section 4.6.2
https://www.freebsd.org/doc/handbook/ports-poudriere.html

You would simply have a network share or http for your poudiere box and set each client machine to the shared package repository.

If your using a mixed environment then a separate i386 and amd64 repository is needed. Same with Arm package building.
Separate repository needed for each architecture.
Just a matter of separate jails for each arch.
 
You must log in or register to reply here.
Back
Top