I'd try nixpkgs before trying pkgsrc if for some reason I wasn't satisfied with ones that come with the distro. Not sure why BSDfying packages is desirable by itself.

One reason to try it might be that pkgsrc mostly solves the problems Nix solves with conflicts in a much simpler way, by allowing multiple co-existing branches installed to different prefixes.

Nothing against nixpkgs, but if the user is curious about how things are done in BSD perhaps he should try xbps before nixpkgs. It was written by a former NetBSD committer who wrote some useful programs for NetBSD's userland. I am biased perhaps but I believe it is faster than any other Linux package manager. Always looking for something faster so I am welcome to being proven wrong on that.

https://github.com/void-linux/xbps

As a pkgsrc committer, xbps is nothing like pkgsrc. The underlying stuff is much more similar to something like Arch or Alpine Linux than anything that exists in the BSD world, and it's much less configurable than pkgsrc.

Care to be more specific than "underlying stuff". The code and design of xbps looks nothing like the code or design of pacman or apk.

Actual package recipes. BSD-style packaging systems are written in BSD make using a mk/ framework rather than Arch-style shell scripts. If a package already exists for FreeBSD Ports I would check that first because it's much more similar to what I'm used to.

Fundamentally pkgsrc is built on very low level tools, awk, shell, make, cwrappers, and pkg_install, although you can manage it with high-level ones (obviously pkgin is there, but there's also a lot of other third-party tooling).

Why are you comparing pkgsrc to pacman. The orginal comparison suggested in the parent comment was between xbps and nixpkgs or other Linux package managers.

pkgsrc boostraps itself using a program called "boostrap" in the pkgsrc directory. It builds a version of NetBSD's GCC toolchain and has no reliance on the host's userland. IME, this is very reliable and is its single greatest strength. Beyond that, pkgsrc is only as good as the build processes chosen by the author(s) of the software being built. These of course vary widely in sanity and depending on the packages one is building the otherwsise sane pkgsrc build process can quickly become a black box with packages that pull in many dependencies. It does break sometimes, but this is a fault of the target software authors, not pkgsrc. pkgsrc is first and foremost a system for building packages. Linux distributions OTOH tend to be much more focused on binary package managers. Most Linux users do not build packages from source. There is really no comparison.

Your comments do not sound like those of a daily NetBSD user. I have been one for the last 15 years and am therefore all too familiar /usr/share/mk. Most Linux users do not seem very comfortable with BSD makefiles.

> Why are you comparing pkgsrc to pacman.

The original commented suggested that XBPS was similar to pkgsrc. I suggested that XBPS has far more in common with Arch Linux's package manager than pkgsrc or anything else in the BSD world. As you yourself note in your next paragraph...

> Your comments do not sound like those of a daily NetBSD user.

I have commit access. Since three years ago. My name is on the latest release announcement.

You prick.

That's not nice and totally uncalled for. Three years is a very short time.

The original comment did not compare xbps to BSD package managers. What it said was that xbps was written by a former NetBSD developer and thus arguably has different qualities than other Linux package managers. It is a different approach from someone with different sensibilities than a Linux developer. I have read comments from Void Linux mantainers and users that say more or less the same thing.

Can xbps be used on foreign distros like pkgsrc? I'd be down to try it out on Ubuntu and NixOS if it supports that

I've been thinking of delegating mandatory crapware like zoom to my mobile phone. Needing to run stuff like that a few times a year is probably not worth preventing me from using an OS.

pkgsrc does work on Linux, but pkgin does not. I have no idea how to update my mirror and so forth using pkgsrc alone. Do not I need pkgin? I cannot do `pkg_add` at all.

I tried to make pkgin work, too, and I think it is possible to make it work with libbsd but I do not have the time. I wonder if anyone has done it.

I am the pkgin maintainer, and would be interested to hear about any issues you have building pkgin. It should build on any of the 23 platforms that pkgsrc supports, including Linux.

I even offer daily binary package builds for CentOS here: https://pkgsrc.joyent.com/install-on-linux/

Feel free to open up an issue at https://github.com/NetBSDfr/pkgin/issues and we can take a look.

Those binaries even sometimes work on Ubuntu, with a little manual linking and good luck, even though it's a total abuse. :D

I am trying to compile it from source on Linux.

I immediately ran into an annoying issue, which is having the need to specify those directories manually. So I did, and the configure finished successfully when I ran:

  ./configure --prefix=/home/john/.local/pkg/pkgin-20210529 --with-dbdir=/usr/ --with-libarchive=/usr/ --with-libfetch=/home/john/Downloads/libfetch-2.33 --with-openssl=/usr/ --with-sqlite3=/usr/ --with-pkg-install=/home/john/.local/pkg/pkgsrc-2021Q1/sbin/ --with-machine-arch=x86_64

When I ran `make`, I ran into:

  actions.c: In function ‘verb_flag’:
  actions.c:53:3: error: implicit declaration of function ‘strlcat’; did you mean ‘strncat’? [-Werror=implicit-function-declaration]
     53 |   strlcat(pkgtools_flags, "v", 1);
        |   ^~~~~~~
        |   strncat

Which tells me that I could fix it by providing `-I/usr/include/bsd/` and `-lbsd` or the like. I will give it a go. Any ideas anyway?

Edit: I added the above, and it went on to:

  In function ‘strncpy’,
      inlined from ‘read_repos’ at fsops.c:133:6:
  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 8192 equals destination size [-Werror=stringop-truncation]
    106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This does not sound too good, you probably want to fix it (along with the other warnings on Linux). In any case, I got rid of `-Werror` and I have a couple of undefined references. I will most likely get it to work, but you see my issue here, right? Is it the "official" way to compile it from source by the way?

Edit #2: I got a working binary by making those changes[1]. Last few lines:

   CCLD     pkgin
  /usr/bin/ld: external/pkgin-var.o: in function `var_get':
  /tmp/pkgin/external/var.c:99: warning: This function cannot be safely ported, use getline(3) instead, as it is supported by GNU and POSIX.1-2008.
  make[1]: Leaving directory '/tmp/pkgin'

---

You might want to look into compiling it on Linux, because without those changes[1], you cannot do it. I was using commit e963d1e1a2409ed51d191d936b5f75e35bdf9197, version 20.12.1.

[1] You also have to include `<bsd/string.h>` for `strlcpy` on Linux. Only `actions.c` is affected.

---

If you want, I am willing to send you an e-mail with the diff, but I will fix the other warnings, too, then. Oh, and instead of relying on `libbsd`, one could just add `strlcpy` and the like themselves.

---

By the way, from where do I get the `repositories.conf` exactly? The supplied `repositories.conf` seems outdated. I tried using both `ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/5.1/All` and `http://mirror-master.dragonflybsd.org/packages/$arch/DragonF...`, but they were not working.

Hmm, I tried to use a working one, but I got this:

  processing remote summary (https://pkgsrc.joyent.com/packages/Linux/el7/trunk/x86_64/All)...
  SSL support disabled
  SSL support disabled
  SSL support disabled
  pkgin: Could not fetch https://pkgsrc.joyent.com/packages/Linux/el7/trunk/x86_64/All/pkg_summary.gz

I am currently using `file://` that points to the manually downloaded `pkg_summary.gz`. Not sure why SSL support is disabled when I configured it, it specifically asked for it, and I provided it through `--with-openssl=/usr/` and it passed because it found it.

  http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/7.1/All/

seems to work!

Although I do get:

  pkg_add: Warning: package `bootstrap-mk-files-20180901' was built for a platform:
  pkg_add: NetBSD/x86_64 7.0 (pkg) vs. Linux/x86_64 5.8.0 (this host)

So how would I remedy this for Linux? I want to use "https://pkgsrc.joyent.com/packages/Linux/el7/trunk/x86_64/Al..." but I get "SSL support disabled". I will debug this I think.

---

I fixed it. I had to compile libfetch with `-DWITH_SSL'.

---

All in all, there are many problems that I ran into, but nothing that much of a big deal.

---

There is one problem I cannot seem to fix:

  pkg_add: unable to verify signature: Signature key id 4735b9a256aaacaf not found

I keep getting this, and I have no clue how to change it or where it came from. Without this, nothing actually gets installed, so I cannot use pkgin or pkg_* until this is resolved. Do you have any clue? I tried to look for anything to change in pkg_install.conf or mk.conf but to no avail. Any ideas?