Solved Which is the best approach to build a single package from ports?

S

ser22

Hi all,

I haven't been yet in the situation where I had to install from ports or build any packages, until now :)

In this case, I simply wanted to install www/nginx-full in a jail, as a reverse proxy with the --with-mail option.
I already have checked ports-mgmt/poudriere and ports-mgmt/synth, but I wanted to ask for advice about the best way to build/install this port and manage the future updates.

Thanks in advance
S-
 
I have given it some further thought.

I don't remember why I was fixated with the idea that I needed to build the port when I could simply null-mount the ports' tree inside the jail and install it.

Thanks all.
 
Both poudriere and synth works well and do the job. Poudriere is more complete/complex feature-wise and it's widely used by most developers and maintainers (said that, it doesn't mean that is harder to learn), while synth is more simple and easier and probably a good choice if you want simple builds (such as yours). You can install the port by hand (mixing with binary packages) if you know what you're doing and if the package doesn't push too much deps in a matter of complicating things up (I'm not sure if nginx do that). I think is a matter of trying both and see what is better for you.
 
When I compile out of tree SeaMonkey it is my only port.
So my philosophy is to use all packages except SeaMonkey port.
/usr/ports/www/seamonkey # env "USE_PACKAGE_DEPENDS=1" make reinstall

My point being if you only need an option in a single application you may be able to mix a port with packages.
I feel with that approach it is best to use packages instead of building every port dependency from ports.
Plus it is much faster. You just need to develop an approach for updates.
(ie. Lock your custom nginx package ( pkg lock nginx) and manually update nginx via ports tree as needed)
Try and keep ports tree close to packages. Using 'latest' package branch is best to keep close to ports tree.
That way pkg updates go smooth.
 
The only side effect I have experienced is when I have not updated my out of tree SeaMonkey.
The pkg system ends up ahead on my machine and a library file will get advanced.
Commonly the situation on Mozilia is this:
SeaMoney will need this
/usr/local/lib/libicuuc.so.69

But the pkg update has put this on my system as an update.
/usr/local/lib/libicuuc.so.70

So SeaMonkey can't find a needed library file.

Dirty hack is cp /usr/local/lib/libicuuc.so.70 /usr/local/lib/libicuuc.so.69
Then you end up with hacky files unregistered with package system. There for eternity.
I have had to do this more than once.

That is the worst of it and it really is no big deal.
I pull up a terminal window, fire SeaMonkey by hand, and see what library it is complaining about.
I take backups before updates and have been known to pull these old deleted libraries from there.
Slightly less hackish.
 
ser22 said:
… In this case, I simply wanted to install www/nginx-full in a jail, …
Click to expand...

I can't comment on the jail aspect, but incidentally (at the time of writing):

[00:01:22] [02] [00:00:41] Skipping www/nginx-full | nginx-full-1.20.2_7,2: Dependent port devel/google-perftools | google-perftools-2.9.1_3 failed

1647251701249.png

14.0-CURRENT
 
I'd suggest building either in a dedicated "buildjail" to keep the host clean or use ports-mgmt/portmaster with the '-P' (or '-PP') option, which installs all dependencies (if possible) from pkg and only builds the specified port. This keeps the system somewhat clean in terms of "mixing ports and packages", otherwise you may sometimes get a lot of those built packages listed for re-installation at the next "pkg upgrade".
As Phishfry already pointed out it also makes sense to pkg lock the port you built with custom options (nginx), so pkg won't reinstall it because of the changed options.

If you have multiple hosts that need this (or other) ports with differing options from pkg, you might want to set up a poudriere host and local repository for those ports. pkg can use multiple repositories with different priorities, so you can give the locally built packages precedence over the ones from the official repositories and don't have to build each and every package that you need on your servers.
 
grahamperrin said:
I can't comment on the jail aspect, but incidentally (at the time of writing):

[00:01:22] [02] [00:00:41] Skipping www/nginx-full | nginx-full-1.20.2_7,2: Dependent port devel/google-perftools | google-perftools-2.9.1_3 failed

View attachment 13328

14.0-CURRENT
Click to expand...

Yeah, it seems I'm just better off using www/nginx to enable the mail module.
 

Attachments

  • Screenshot from 2022-03-15 09-48-35.png
    Screenshot from 2022-03-15 09-48-35.png
    125.2 KB · Views: 137
I had never heard of the command you came up with here.
make install-missing-packages
It is great FreeBSD has so many different ways to build software.
Phishfry said:
env "USE_PACKAGE_DEPENDS=1" make install
Click to expand...
Will the "env" setting survive the FreeBSD 14 root shell change?
Is 'env' command the same across all shells?
 
Last edited:
Phishfry said:
Is 'env' command the same across all shells?
Click to expand...
env(1) works the same across shells.

Code: 
dice@molly:~/test % cat test.sh
#!/bin/sh

echo $foo

dice@molly:~/test % echo $SHELL
/bin/tcsh
dice@molly:~/test % env foo=Hello ./test.sh
Hello
dice@molly:~/test % sh
$ pwd
/home/dice/test
$ env foo=World ./test.sh
World
$ ^D
dice@molly:~/test %
 
Thanks,

SirDice said:
env(1) works the same across shells.
Click to expand...

Weird. I always assumed that sh required a different format because of e.g. what's seen in ~/.profile, stuff like this (the fourth line):

Code: 
# Setting TERM is normally done through /etc/ttys.  Do only override
# if you're sure that you'll never log in via telnet or xterm or a
# serial line.
# TERM=xterm;   export TERM

Afterthought: I'm thinking of setenv, not env.
 
/usr/bin/env is an external tool, not a shell builtin. Different shells have different ways of setting environment variables (setenv(1) on csh(1) for example) but env(1) is standalone, it just sets environment variables and executes the command with those environment settings.
 
When i need to build a single package from ports, i do install the depends via pkg and then build the port.

After installation i do remove the build depends.

But its important that pkg and ports are from the same repo.
 
You must log in or register to reply here.
Back
Top