I'm a bit confused now about installing software, after having seen a discussion on the NetBSD IRC channel. It was mentioned these two methods should not be used at the same time, on the same system. I understand the binary packages are all bulk built together, in a single environment, and that substituting them with pkgsrc build packages could lead to problems. However, I do not understand how it would be problematic to build pkgsrc packages in an additive manner, in other words, using binary packages for all the dependencies, but using a pkgsrc compiled package at the top level (nothing depends on it). This would be for a system using binary and pkgsrc, synced to the same quarterly release.

What am I failing to understand here? There's a different OS I use, which seems to be superficially structured similar to NetBSD, in having an "integrated base system install" and methods for installing third-party binary packages and a pkgsrc-like build-from-source method of creating packages to install. However, it does not seem to share this "either/or" restriction with regards to packages.

  • pin replied to this.

    zoomzoom It was mentioned these two methods should not be used at the same time, on the same system.

    What you should most definitly not do is, mix things from different Q-releases or, from Q-release and current.
    And, you shouldn't use modular-xorg bits with the official binary packages, even though a few thing would probably work.

    zoomzoom I understand the binary packages are all bulk built together, in a single environment, and that substituting them with pkgsrc build packages could lead to problems.

    If you understand this, I'd guess you'd be able to identify potential issues and maybe fix them 🙂

    zoomzoom However, I do not understand how it would be problematic to build pkgsrc packages in an additive manner, in other words, using binary packages for all the dependencies, but using a pkgsrc compiled package at the top level (nothing depends on it).

    I can see a few potential issues with it in certain situations but again, chances are, if you understand the system, you might recognize the issues and be able to fix a work arround.

    zoomzoom This would be for a system using binary and pkgsrc, synced to the same quarterly release.

    This makes it less likely to be problematic.

    zoomzoom There's a different OS I use, which seems to be superficially structured similar to NetBSD, in having an "integrated base system install" and methods for installing third-party binary packages and a pkgsrc-like build-from-source method of creating packages to install.

    Are you using Void with packages from xbps and xbps-src? Void base is different from and, smaller than NetBSD base but, yes there are similarities, xbps was created by a previous NetBSD dev.

    zoomzoom However, it does not seem to share this "either/or" restriction with regards to packages.

    Linux and NetBSD are different and, I won't go against the general recommendation of not doing this.
    What I can tell is that, if you know what you are doing and can troubleshot things, you'd probably be fine.
    For the record, I do mix things between them, I even mix things built from git-HEAD through pkgsrc but, I don't expect others to have answers if I break things.
    All in all, it depends on your will to understand potential issues and be able to handle them. But, sure it's possible, even though it's not recommended. At the end of the day it's your call.

                  You also need to be aware:

                  (a) that pkgsrc-wide mk.conf settings are the same
                  (b) that anything you install may be overwritten by a binary package upgrade.

                  I'd say this is only useful for pkgsrc-wip, which isn't guaranteed to work perfectly in combination with a quarterly release.

                  It's much more useful to bootstrap pkgsrc-current to a separate prefix (maybe even unprivileged in your home directory) if you want to do development.

                    Using pkgin with binary packages for most people, should be more than fine.

                    Using pkgsrc (compiling from source) is considered more advanced and sometimes could potentially lead into breakage (especially if you are mixing packages). If you have time and knowledge, you will most likely overcome any issue that arises, but this is not something an every-day casual user wants to get into.

                      Mosfet this is not something an every-day casual user wants to get into

                      Every-day casual users probably won't use NetBSD anyway 🙂

                        pin

                        And, you shouldn't use modular-xorg bits with the official binary packages, even though a few thing would probably work.

                        I've done that before, before knowing better 😅

                        Are you using Void with packages from xbps and xbps-src? Void base is different from and, smaller than NetBSD base but, yes there are similarities, xbps was created by a previous NetBSD dev.

                        No, Slackware, which is not exactly one-for-one, but it has a lot of BSDisms compared to other Linux distributions. It has a very narrow general recommendation of "full install" as that is what testing is based on. So if you remove or skip packages, it's expected that you can troubleshoot the problem to figure out dependencies or version conflicts.

                        Linux and NetBSD are different and, I won't go against the general recommendation of not doing this.
                        What I can tell is that, if you know what you are doing and can troubleshot things, you'd probably be fine.
                        For the record, I do mix things between them, I even mix things built from git-HEAD through pkgsrc but, I don't expect others to have answers if I break things.

                        Ok, my main concerns would be things like corrupting the package database or causing irreversible damage to the OS, problems that would likely require a new installation or be arduous to fix by hand. I guess I wasn't quite sure what was meant by "not safe". Does that mean "untested", in the sense it is unknown if the program will compile, run or be stable? Or should it be avoided because it will lead to database corruption, damaged FS, randomly deleted files, etc.

                        • pin replied to this.

                            nia
                            One instance where I remember doing this:
                            I had installed Netsurf 3.8 with pkgin, but that specific version had a critical usability problem that made it non-functional. pkgsrc-current had version 3.9, which corrected the problem, so I temporarily changed Netsurf in pkgsrc to current, updated, built, installed, cleaned, and switched Tag back to quarterly.

                            • pin replied to this.

                                zoomzoom my main concerns would be things like corrupting the package database or causing irreversible damage to the OS, problems that would likely require a new installation or be arduous to fix by hand. I guess I wasn't quite sure what was meant by "not safe". Does that mean "untested", in the sense it is unknown if the program will compile, run or be stable? Or should it be avoided because it will lead to database corruption, damaged FS, randomly deleted files, etc.

                                I believe you know how to handle these sort of things and corrupting the package database is highly unlikely, pkgin is smart enough.

                                The major issues you could run into are missing/conflicting shared libraries versions or as @nia pointed out the package manager overwriting your changes during an update. AFAIK, pkgin is not able to hold specific packages. There're possible work arounds for the later but, I won't be recommending anything right now.

                                • Jay likes this.

                                  zoomzoom Another solution would be to set-up pkgsrc-wip, copy the version from current into it and build it there instead of shifting back and forward between trees.

                                  • Jay likes this.

                                    Pro tip: on NetBSD if you fuck up you can always rm -rf /usr/pkg /var/db/pkg*