Very interesting, I didn't know pkgsrc could be used on Linux, I'll check it out. In general the only things keeping me from BSD are non free apps like Zoom so the next best thing is to BSDify my systems.
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).
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.
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.
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.
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 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.
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
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
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));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/7.1/All/
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)
---
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