Connor McLaughlan <cont6pro3%gmail.com@localhost> writes: > I first tried to run debian as a base and to replace their non-working > software packages with pkgsrc ones. This worked very well and most > software would compile and run. > This teached me the need for bootstrapping. > > But after a while i figured that some packages would only compile on > NetBSD. So I switched the base system to NetBSD to get broader > software possibilities. > > There are websites and tutorials that tell to bootstrap also on > NetBSD, so I kept it that way: > https://opensource.com/article/19/11/pkgsrc-netbsd-linux Interesting but as I see it the standard approach on NetBSD is to just use pkgsrc. It basically comes with the things you need in base, configure for /usr/pkg. However, it is unlikely that this is your issue. I recommend using the built-in support so your system matches the binary packages you are using. > So far pkgsrc provides the most working software, but is also in a > slightly inconsistent state with packages requiring others that are > not available or not compiling in a current quarterly release. So I > was forced to mix old and new releases to get some stuff working. Well, not quite. Mixing branches takes you into undefined behavior territory. It might work and it might not. You can also checkout pkgsrc HEAD and build that. Then you can fix what's wrong (often upstream things) and that will make the next branch better. > This was under the impression that a quarterly release is some kind of > a stable and checked thing, when it really seems to be just a snapshot > of a quarterly cvs state. It is more towards stable. While we do simply make a branch, we have a period leading up to it where packages don't get updated, and people try to make everything work. With 20K packages and 20 operating system and N cpu types per OS, it is infeasible to check everything. Not that many people build for sparc64, so upstream packages that don't build on that tend not to get noticed and fixed. If you look at the NetBSD 9 amd64 build results for 2020Q2 you'll see that almost everything builds. > I am not using cvs because the old machines are slow and I am in fear > of constant recompiling on every slight update. > This might change once NetBSD starts to support sparc64 T1 - T5 cpus. > Fast and parallel compiling should be possible then. What I would recommend is: 1) if there is a binary build of a quarter, check out that quarter, and also install binaries A) if there is a package that is missing, try to build it, figure out what's wrong, and build it (on the branch). merge the patch to HEAD and send that in. B) Alternatively,update that package to HEAD (with -A in a subdir). Note that this is not really a good idea, but if you lack adequate CPU time (which I believe; I ran a sparc classic until 2017), you are left with only more bad and less bad choices. Then try to build and fix. You may have to update mk, and other things. Harder usually, but the newer upstream version might have fixes. C) build the upstream package outside of pkgsrc. Send fixes to them. Apply them to pkgsrc as patches once you understand. > So all in all i am pleased. pkgsrc is currently the best way to have a > modern desktop and software on these machines. I agree. I think you are struggling less than you'd be without it!
Attachment:
signature.asc
Description: PGP signature