Solved What are good practices when building my own packages?

mariourk

mariourk

Hi,

I want to migrate my mailserver to a new one. So I'm in the process of installing and building a new mailserver. However, the Postfix package doesn't come with PostgreSQL support build-in, which I happen to need. I know it's bad practice to throw both packages and ports into the mix. And since I don't want to compile all the software I need, I want to stricktly stick to packages. So I created a jail, compiled Postfix with all the build flags I needed and create a packages from that build. Then I copied the freshly build package back to the host and installed it with pkg add -f postfix-3.5.2,1.txz. So far so good. But when I tried to start Postfix, it complained that it wanted libicuuc.so.67.1. And that was a problem, because on the host (with everything installed via pkg, remember?) it was still on libicuuc.so.66.1.

Facing this dilemma, I figure I have a few options.
  1. Try to downgrade everything in the build-jail and rebuild everything with the same version as the host.
  2. Make a package of devel/icu and install the newer version on the host, but risking breaking already installed packages, depending on the older version.
  3. Build a static package.

I wanted to build a static package, but this doesn't seem as trivial as I hoped. I eventually went with option 2 and forced the newer version devel/icu on the host. This solved my problem, but I'm not so confident it will work a second time.
So, what's the best practice in this scenario?
 
mariourk said:
I know it's bad practice to throw both packages and ports into the mix. And since I don't want to compile all the software I need, I want to stricktly stick to packages. So I created a jail, compiled Postfix with all the build flags I needed and create a packages from that build.
Click to expand...

No, "bad practice" referes to mixing packages built from different sources and/or with different compilation options.
 
mariourk said:
So, what's the best practice in this scenario?
Click to expand...
Set up your own build server so you can build your own repository. This sounds more complicated than it actually is. Yes, you will need to build everything you need from ports but this can all be done more or less "offline". With your own repository you get a lot of benefits. The most important is that you can define your own default versions (maybe you want to base everything on PostgreSQL 12 for example). You also get to switch all options on or off. As everything is built from the same repository your dependencies are going to always line up. And last, but not least, you get full control over updates.
 
SirDice said:
Set up your own build server so you can build your own repository. This sounds more complicated than it actually is. Yes, you will need to build everything you need from ports but this can all be done more or less "offline". With your own repository you get a lot of benefits. The most important is that you can define your own default versions (maybe you want to base everything on PostgreSQL 12 for example). You also get to switch all options on or off. As everything is built from the same repository your dependencies are going to always line up. And last, but not least, you get full control over updates.
Click to expand...
This sounds like a good solution for me. Do you recommend any documentation on how to do this?
 
There should be some Synth and Poudriere howtos in the howto section. Poudriere is the tool that's used to build the official packages. Synth is set up slightly different, it has a different use-case. But both will allow you to give it a list of things you want and let them build the packages for it. That end result can easily be shared or exported with a simple nginx or Apache config. All you need to do on the 'clients' is to create a custom repository in /usr/local/etc/pkg/repos/ and you can use pkg(8) to install/update from your own repository. It takes a bit of fiddling to set up but once you have it up and running there's very little to do to keep it maintained.
 
SirDice said:
There should be some Synth and Poudriere howtos in the howto section. Poudriere is the tool that's used to build the official packages. Synth is set up slightly different, it has a different use-case. But both will allow you to give it a list of things you want and let them build the packages for it. That end result can easily be shared or exported with a simple nginx or Apache config. All you need to do on the 'clients' is to create a custom repository in /usr/local/etc/pkg/repos/ and you can use pkg(8) to install/update from your own repository. It takes a bit of fiddling to set up but once you have it up and running there's very little to do to keep it maintained.
Click to expand...
Ok, I'll look into it.

Maybe this sounds stupid, but what do I do between major and minor FreeBSD upgrades? Upgrade de buildserver, rebuild the packages, upgrade the client and update the packages?
 
I use Poudriere and with that it's easy to build packages for other FreeBSD versions (and even architectures). At the moment I only have 12.1-RELEASE and 12-STABLE so I have two repositories (one for each version). During migration updates/upgrades (new minor or major version) I will create new jails for those versions and let it built beforehand. The only thing you need to remember in this case is that your build server must be the same or higher version than the build jails. So in order to build for 12.1-RELEASE your build server has to be 12.1-RELEASE or newer. Therefor I update my build server first then let it build packages for the new version. Once that's done I will start updating/upgrading the other machines.
 
SirDice said:
I use Poudriere and with that it's easy to build packages for other FreeBSD versions (and even architectures). At the moment I only have 12.1-RELEASE and 12-STABLE so I have two repositories (one for each version). During migration updates/upgrades (new minor or major version) I will create new jails for those versions and let it built beforehand. The only thing you need to remember in this case is that your build server must be the same or higher version than the build jails. So in order to build for 12.1-RELEASE your build server has to be 12.1-RELEASE or newer. Therefor I update my build server first then let it build packages for the new version. Once that's done I will start updating/upgrading the other machines.
Click to expand...
Hmm, I wanted to put my buildserver into a jail. But since the buildserver has to be updated first, that's going to be tricky. Is it possible to do this with Bhyve? In other words, can Bhyve run a newer FreeBSD version that the host?
 
mariourk said:
Then I copied the freshly build package back to the host and installed it with pkg add -f postfix-3.5.2,1.txz. So far so good. But when I tried to start Postfix, it complained that it wanted libicuuc.so.67.1. And that was a problem, because on the host (with everything installed via pkg, remember?) it was still on libicuuc.so.66.1.
Click to expand...
You are mixing quarterly packages ( libicuuc.so.66.1 ) and head ports tree ( libicuuc.so.67.1 ). The quarterly package repository is set as default in /etc/pkg/FreeBSD.conf. portsnap(8) checks out the head ports tree. You can mix packages and ports under the condition you track the same ports tree and the program you wish to install has not a long list of dependencies. As the list of dependencies gets longer, more easely things can break. To get a quarterly ports tree a version control system like svnlite(1) is necessary.

In case you wish to build packages with ports-mgmt/poudriere decide which ports tree you wish to follow first.

With ports-mgmt/synth it is also important to choose which ports tree to follow. As shkhln mentioned synth can prefetch packages ( if the packages have unmodified ports configuration options ), but if the ports tree and the default package repository don’t match, synth will always build from ports.
 
You must log in or register to reply here.
Back
Top