1. 2

    `pkg` is a very minimal looking package manager. It doesn’t have very many frills and it is integrated into the system pretty darn well

    Not quite sure what you mean by this. pacman and dnf and apt don’t really do anything that pkg doesn’t. pkg is if anything bloated compared to the other package managers I mentioned. It even supports plugins!

    1. 5

      I was with you with pacman and dnf, but … apt/apt-get/dpkg do a lot of things (hello dpkg-reconfigure!).
      If you want to talk about svelte, apk (alpine) is probably a better comparison.

      1. 3

        Well, pkg doesn’t have hooks, alternatives, GPG keyring stuff…

        1. 1

          Hooks are there now (called triggers). For alternatives we talked about them recently with bapt@ and we think that we have found a simple yet effective way to implement them. For GPG stuff no one is working on that afaik so feel free :)

          1. 5

            The most overlooked features in pkg is, to my mind pkg audit (replacing the old portaudit). I miss it on every other system: a command that tells me if there are any CVEs in my installed packages.

            1. 2

              I miss it on every other system: a command that tells me if there are any CVEs in my installed packages.

              vulnix offers this for Nix/NixOS:

              https://pypi.org/project/vulnix/

              1. 1

                On Debian, install devscripts package and run rc-alert.

              2. 1

                I didn’t say the GPG stuff is a good thing :D

          1. 3

            Due to the way FreeBSD designed the package manager, we’ll not be able to provide packages for the 12.2-RELEASE branch since we put the priority on 12-STABLE.

            Why is that ? You could always tweak the server url used, not relying directly on $ABI or something else.

            I’d really like to know what’s really preventing you to do packages for 12.2-RELEASE and 12-STABLE.

            Also, I guess that same as FreeBSD all packages (except kmods) compiled on 12.2-RELEASE would work on 12-STABLE.

            1. 1

              Because we rely directly on $ABI. We don’t have the ability with our limited infrastructure to migrate to something more specific than $ABI. We’re stuck with the original recommendations from years back. Given that and our preference for supporting 12-STABLE, we can’t provide packages for both 12.2-RELEASE and 12-STABLE (since, like you mentioned, kmods would be broken for one or the other.)

              1. 2

                So that have nothing to do with how pkg was designed then.

                I would be glad if you could update the article to reflect that.

                Thanks

                1. 1

                  If only pkg was designed to handle minor version numbers…

                  Designing default settings is part of application design.

                  FreeBSD suffers from this problem, too.

                  1. -2

                    pkg itself doesn’t really know or care about major/minor version numbers.

                    The default settings of using $ABI isn’t from pkg, it’s from FreeBSD default pkg.conf

                    There is nothing preventing you to build and distribute packages usable by pkg(8) for HardnenedBSD 12.2 and 12-STABLE.

                    Saying otherwise is fake news as your beloved president would say.

                    1. 4

                      Saying otherwise is fake news as your beloved president would say.

                      Really? Of all places, you’re gonna go there? Even I thought you were better than that. Disappointing, to say the least.

                      Conversation with hostile upstream ended.

                      1. 1

                        https://github.com/freebsd/pkg/blob/master/src/pkg.conf.sample#L26

                        https://github.com/freebsd/freebsd/blob/master/usr.sbin/pkg/FreeBSD.conf.quarterly#L11

                        $ABI comes from detection logic in pkg(8). It parses the ELF headers of some executable expected to exist on FreeBSD. Thus, $ABI comes from pkg(8), which is FreeBSD’s package manager.

                        1. 3

                          Yes, and you made the choice of using it in your repo.conf

                          You could use $VERSION_MAJOR/$VERSION_MINOR too and produces packages for 12.2 (and leave $ABI for 12-STABLE for example). Those variables are just unused on FreeBSD but you can make the choice of using them.

                          pkg(8) knows about everything on the OS version but don’t really care about it, the only check it will do is compare the elf note of the running machine with the one used to compile the packages if you have IGNORE_OSVERSION=no which is the default).

              1. 1

                How is this related to https://github.com/freebsd/freebsd/? The commit hashes don’t match the tree on GitLab.

                  1. 1

                    Wow, that’s… wow. The description of how vendor branches are going to work to avoid using submodules makes me so very glad I don’t maintain anything in contrib. Thank you for your work keeping dtc in sync, I’m sorry to hear that the git working group has decided to make your life harder than it needs to be.

                    1. 1

                      What is the best way to handle vendor branches in cases like this?

                      1. 2

                        If you don’t have an allergic reaction to submodules, clone each of the upstreams and then the directories in the contrib directory submodules. Keep an upstream branch in each of the cloned repos and a contrib branch that carries any changes you’ve made. It requires users to add –recurse when they clone and pull, but given how many things use submodules now that’s a pretty common requirement. If you don’t have any changes, then the submodules just points at your mirror of the upstream. If you do, then having a self-contained git repo for that project makes merging relatively painless and preserves history. If you’re happy to burn some CPU cycles, you can use git-imerge in rebase-with-history mode every time you pull from upstream to give a clean history of your changes applied on top of upstream, while also making it possible for people who have local changes to merge your new version. In both cases, you update the shared version by just bumping the submodule version. Your main repo’s history just contains a hash and, for extra benefits, people can clone the whole history of your project but use shallow clones of the submodules to avoid having, for example, the entire history of the LLVM versions that you’ve shipped.

                        1. 1

                          It requires users to add –recurse when they clone and pull, but given how many things use submodules now that’s a pretty common requirement.

                          I keep all my vim plugins as submodules in .vim/bundle and every single time I’ve ever cloned my .vim I’ve gone:

                          $ git clone $URL
                          $ ln -s .vim/vimrc .vimrc
                          $ vim 
                          oh, no plugins, wtf? oh ffs
                          $ rm -rf .vim
                          $ git clone $URL --recurse-submodules
                          $ vim
                          :Helptags
                          

                          I don’t think I’ve ever remembered it once, and I can never remember the command for submodules. Is it git submodule init --update? Or git submodule update --init? Easier to just clone again with --recurse-submodules.

                          Your main repo’s history just contains a hash and, for extra benefits, people can clone the whole history of your project but use shallow clones of the submodules to avoid having, for example, the entire history of the LLVM versions that you’ve shipped.

                          And of course they do have the full history of the LLVM versions that you’ve shipped if they want them, they just don’t have to if they don’t want them. It really is the best of both worlds.

                          I must say I find keeping submodules in sync with what they’re meant to be just bizarrely painful, though. Do you know of any way to just say ‘always keep the submodules at whatever commit they’re meant to be’?

                          1. 1

                            I must say I find keeping submodules in sync with what they’re meant to be just bizarrely painful, though. Do you know of any way to just say ‘always keep the submodules at whatever commit they’re meant to be’?

                            There’s a bot on GitHub that notices if your submodules are out of date and sends a PR to update it. I’m not sure if you have to explicitly opt in to it (it seems to run on everything in the Microsoft org).

                            I know that several of my colleagues have just added some custom git verbs to handle them (and also do common things like stash, update, stash pop), so never have to deal with the core git UI abominations for them.