1. 8
  1.  

  2. 2

    Once a month for freebsd-update worries me slightly, unless you’re also subscribing to -announce and rolling out any security updates. Some time last year, we started getting VuXML entries for the base system, so the daily security report emails will contain those if you’ve enabled it, in addition to security warnings for third-party packages.

    We all know the ‘default’ rule that mixing Packages and Ports is a bad idea in the FreeBSD world – and I generally agree – its a bad idea if you do not know what you are doing.

    And using a ports tree in any way without Poudriere is a really good sign that you don’t. Please don’t recommend that anyone runs portsnap directly. Poudriere can run it (though, given how slow portsnap is, telling Poudriere to use git instead will be better) for the ports trees that it manages.

    1. 1

      Currently I do not need to build any packages - but there was time when FreeBSD did not provided lame package - so also ffmpeg needed to be rebuilt with lame support. Same for exFAT related ports. Now all of them are available as packages so no need to rebuilt.

      1. 1

        There are a lot of ports with options that might lead people to want a custom build, but building the, in an environment with other packages installed in the host system can cause unexpected build failures (a lot of things will detect other packages that are installed and use them, possibly in unexpected ways, and without tracking them as dependencies). This then leads to users filing bug reports and complaining that ports are broken because their environment is or something that the port maintainer ever expected. Using Poudriere prevents any of these issues and makes it much easier to build package sets than trying to build manually outside of a jail. Any instructions to do anything with the ports tree that do not tell users to use Poudriere are doing them a disservice.

        1. 1

          Like I said in the first place - you have to know what you are doing …

          1. 2

            But you learn what you’re doing by reading online tutorials and if the online tutorials tell you to do the wrong thing then you will never learn.

    2. 2

      I’m still waiting for pkgbase…

      1. 1

        So am I. It’s nearly there, but the fact that pkg can’t merge config files is the big problem at the moment. It installs a load of /etc/ files and saves yours as .pkgsave and then you need to manually merge them. It’s probably not much work to teach etcupdate to handle them and to teach pkg to run etcupdate, but I don’t have time to work on it.

        1. 1

          That’s not true. pkg obviously knows how to merge config file. The .pkgsave files are created if the file wasn’t part of a package (previously it silently deleted the target file). So yes the bootstrap phase of switching an existing FreeBSD installation to a pkgbase one will create a lot of .pkgsave file (in fact every file in the system not only files in /etc). etcupdate isn’t the right tool for that, mainly because etcupdate is useless in a pkgbase installation (I haven’t used this tools for years now).

          1. 1

            I haven’t dug into the root cause, but this happens for every pkg upgrade that I do with pkgbase. Files like /etc/groups get removed and replaced, so I stop being in the wheel group if I don’t make sure I edit them before rebooting. Possibly there’s no package that thinks it owns these files, but on an upgrade from one pkgbase version to the next (not a migration to pkgbase), a load of things in /etc/ get trampled for me. This is a fairly new behaviour, until some time last year I just got pkgnew files and had to manually add new things, rather than having to preserve my original changes.

            I couldn’t find any docs on how to make pkgbase properly merge config files.

            1. 1

              /etc/group is owned by FreeBSD-runtime (always have been). It might be that you badly did the bootstrap phase and so pkg(8) can’t do the three-way-merge. There is no docs on properly merge config file as pkg(8) does the right thing.

              1. 1

                I followed the instructions from the wiki to do the initial install and have been building a package set and doing the pkg upgrade invocation from the wiki since then. Any ideas how to debug it? It looks as if the ownership is correct:

                $ pkg which /etc/group
                /etc/group was installed by package FreeBSD-runtime-14.{version}