Do not use ports-mgmt/portmaster and other tools who build in the main system

[Mjölnir]

• Please consult Howto build ports with ports-mgmt/poudriere for a set of historically evolved issues concerning the ports tree.
• Please consult the well-known Recursive Make Considered Harmful for reasons why such tools do not handle the build process theoretically sound -- they do not use make(1) correctly to compute the graph of dependencies.
• These tools have other issues, mainly that building in the main system clutters your system with build-deps/build-tools you do not need otherwise.
• Instead, use ports-mgmt/poudriere or ports-mgmt/synth to build your ports.
  These always build in a fresh, clean jail. Installing devel/ccache is optional but common practice, and integration into these tools will save a great amount of build time. The vast majority of ports build fine with ccache.
  This adds a small amount of planing & taking a few decisions, and manual setup & configuration once (~1 hour). The benefit is much less hazzle when building ports until s/th basically changes in these two more advanced build tools.
• Period.

 

[richardtoohey2]

I thought synth was about as popular (with the FreeBSD developers) as portmaster? That is to say, not popular at all.
portmaster for all its faults, works for me, but going forward I'm going to try binary packages with pkg.

My understanding (I could very definitely be wrong!) of the current "best" way of dealing with third-party code is:

1) If you don't need to use ports, then use pkg and binary packages.
2) If you do need to use ports - use poudriere to build the ports (and then, I think, pkg to distribute the binaries you've built).

I've tried poudriere and just found the extra faff of jails etc. too much for my attention span. A few make installs and portsnap & portmaster (to keep things up-to-date) - seems to be easier and work most of the time. BUT it's not liked by the developers who have kindly looked after it.

 

[VladiBG]

I don't agree with above statement.
I'm using FreeBSD from RELEASE 6.0 and back then there was no portmaster script to help you upgrade your ports. The ports was installed manually and then you can upgrade them manually or using portupgrade which i learn and still use today. The portupgrade uses database and depend of ruby so after a while portmaster came as script only replacement of portupgrade with no db dependencies. During build process all ports install the build-deps which then you can remove with pkg autoremove but it doesn't hurt to leave them as you need them again on the next upgrade.
When you need to build packages for different architecture or maintaining a farm of servers which have same program with different build options using only above tools it was a nightmare. To fill this gap poudriere was born which made this build process easy but it didn't replace the other tools like portupgrade and portmaster. Synth came after that as custom repository.

So in short retrospect it was:

2002 FreeBSD 4.5 - ports-mgmt/portupgrade
2007 FreeBSD 6.2 - ports-mgmt/portmaster
2012 FreeBSD 8.3 - ports-mgmt/poudriere
2016 FreeBSD 11 - ports-mgmt/synth

Every tool have different purpose and depending of your goal you can use which suit you best.

If you need to build a program with different build option then you have to stop using pkg and build and upgrade all your programs from the ports. It's a very time consuming especially if you are using GUI as some ports may took days to build and consume huge amount of disk space. Exception of this is only when you need to upgrade the pkg using pkg-static install pkg

 

[Mjölnir]

I don't agree with above statement.
I'm using FreeBSD from RELEASE 6.0 and back then there was no portmaster script to help you upgrade your ports. [...]

You don't have to, because this is not a question of agreement, but right and wrong Did you actually read the two sources/links mentioned above? The dependies of the ports are declared in their Makefiles and tools like so-called portmaster(8) try to process these depencies by-feet (themself) instead of letting the program do it that is dedicated to this - make(1), which is mature since decades and does this well. Of course: there is no make library you can use to integrate this functionality in external programs or scripts; there is no switch to let make write out the computed dependency graph in a parsable format. Did you ever try a command like this

• portmaster -F x11/kde5 (recursively fetch all distfiles needed to build kde5)
  The result is that after more than one hour of uselessly processing the dependency graph, this self-called master still fetches nothing.
• In contrast, cd /usr/ports/x11/kde5; make fetch-recursive starts to fetch the files after a few seconds.

 

[SKull]

I'm afraid I can't answer the poll. The question makes no sense.

I use pkg for pretty much everything.
Only for stuff where I want none default options I use ports.
And I use them with a simple:

make config && make install clean

 

[VladiBG]

tools like so-called portmaster(8) try to process these depencies by-feet (themself)

Can you explain it in details?

btw. did you read the manual of portmaster and did you check the source code of it? (rhetorical question)
Portmaster is a just a big shell script which help you to use the standard tools to track the dependence and upgrade the ports.

 

[zirias@]

• I agree with the recommendation to prefer poudriere. The builds in clean jails avoid a lot of common problems. You need ZFS for efficient operation (so jails can be quickly created from snapshots)
• I'm not sure about synth. It sounds like a good alternative, but AFAIK, it's discontinued. There's dsynth, maybe this is coming to FreeBSD as well?
• The problems have nothing to do with "recursive make", that's a red herring here. Recursive make can have its problems, I agree to better avoid it, but something like the ports tree can't be implemented non-recursive in a sane way, and it still works fine. The whole thing is *only* about the clean build environments tools like poudriere and (d)synth offer, which are crucial to avoid some typical problems.

 

[Sevendogsbsd]

ports-mgmt/synth hasn't had an update in a year but out isn't flagged as "no maintainer" or anything. I used it a few months ago and it worked fine. For building on the machine you are using the ports for, I prefer it to ports-mgmt/poudriere because it is far simpler. Poudriere isn't that complicated but the set up takes a bit of time.

 

[mickey]

• Building and installing software on a live system is exactly the way the ports tree was designed to be used in the first place.
• A clean room environment should not even be necessary. I also wouldn't say it avoids problems, rather that it circumvents problems thereby masking the existence of such problems which in turn makes it more unlikely that such problems ever get addressed.

I have been using the ports tree (and portmaster/portupgrade) almost exclusively from the very beginnings and never had any major headaches I wasn't able to somehow solve by myself. When stuff breaks it is often due to software X version B using a header file or library that software X version A installed on the system, instead of using the correct version that comes bundled with the source. Of course a clean room environment would circumvent such problems, but that is hardly a solution to the problem in itself.

 

[Mjölnir]

Can you explain it in details?

just do portmaster -F x11/kde5 and see how it works... it does not use make but goes by-feet. Do not hesitate: it will not download anything within a reasonable amount of time, so you can cancel it before it starts to fetch the 1st tar ball.

btw. did you read the manual of portmaster and did you check the source code of it? (rhetorical question)
Portmaster is a just a big shell script which help you to use the standard tools to track the dependence and build/install the ports.

Yes I did both when I ran into these kind of bugs. After several hours of trying to understand the source and where I can fix this, I filed in a bug report. A shell script should not have more than about 1k lines of source code. portmaster is beeing rewritten in LUA due to the fact that shell scipts are not suitable for such complex tasks. And no, it is not helpful if a tool that calls itself master violates basic principles of software engineering resulting in the numerous bugs you can find on bugzilla.

 

[VladiBG]

Ok, i will try it

 

[Jose]

This is a matter of some debate on the -ports mailing list. Personally, I'm for separating the build system from the deployment system. I did the compile-and-install on the same machine thing for more than a decade. It works great for snowflake systems, but breaks down badly when you try to automate system setup.

Portmaster, vanilla ports, and derived systems like Gentoo portage don't lend themselves to reproducible system builds. You're going to have to separate building packages from the system they're installed into if you want to build system images automatically. Building the build system is one of the things I hope to automate someday when I slay my procrastination demons.

This is just my opinion. There are plenty on folks on -ports that still use Portmaster and/or expect to be able to install software by doing a make install in the ports tree. This debate is far from being settled. I'm definitely rooting for the Poudriere team, though.

 

[VladiBG]

I see what you mean. When you try to fetch the entire metaport of KDE5 without using the port-index portmaster goes trough all Makefiles to build the depend-list and then start to download the dist under /usr/ports/distfiles

it does not use make but goes by-feet.

It actually use make see bellow

make_dep_list () {
    local dep_type var_opt

    for dep_type in $*; do
        case $dep_type in
        all-depends-list|build-depends-list)
            var_opt="$var_opt -V PKG_DEPENDS -V EXTRACT_DEPENDS \
                -V PATCH_DEPENDS -V FETCH_DEPENDS -V BUILD_DEPENDS -V LIB_DEPENDS"
            [ "$dep_type" = all-depends-list ] && var_opt="$var_opt -V RUN_DEPENDS" ;;
        run-depends-list)
            var_opt="$var_opt -V RUN_DEPENDS -V LIB_DEPENDS" ;;
        test-depends-list)
            var_opt="$var_opt -V TEST_DEPENDS" ;;
        *)
            fail "make_dep_list: Unsupported option '$dep_type'"
        esac
    done
    [ -n "$var_opt" ] && make $var_opt | tr ' ' '\n' | cut -d: -f2 | sort -u
}

portmaster and portupgrade are tools for upgrading already installed ports on the system and they will fail to fetch meta-port which by itself doesn't install files. To fetch such ports you need to use ports(7)

 

[zirias@]

• Building and installing software on a live system is exactly the way the ports tree was designed to be used in the first place.
• A clean room environment should not even be necessary. I also wouldn't say it avoids problems, rather that it circumvents problems thereby masking the existence of such problems which in turn makes it more unlikely that such problems ever get addressed.

I have been using the ports tree (and portmaster/portupgrade) almost exclusively from the very beginnings and never had any major headaches I wasn't able to somehow solve by myself. When stuff breaks it is often due to software X version B using a header file or library that software X version A installed on the system, instead of using the correct version that comes bundled with the source. Of course a clean room environment would circumvent such problems, but that is hardly a solution to the problem in itself.

Strongly disagree with most of that. But let's start with the part I agree with: You have a point about "masking" problems in the sense that: If ports are never tested in an "unclean" environment at all, it's very likely that they will miss any/most necessary *_CONFLICTS, cause these won't show in a clean environment. But OTOH, why even bother, if clean build environments are possible nowadays on virtually any hardware?

Now for my disagreement: The ports tree was designed for, well, building ports Back when it was first created, building on the "live" system was basically the only option. That doesn't mean it isn't suited for usage in a clean build environment. The ports tree always worked as designed, in any environment -- and in an "unclean" environment, you were from time to time required to solve problems that arose because of that environment. If you know what you do, this is very well possible (and, will always be), but even then, it's just annoying to run into these kind of problems (and solving them) all over again. And I'm quite positive it will never be possible to avoid all these problems upfront, cause as a ports maintainer, there's no way to foresee any environmental condition the port could ever be built in.

So, agree with another statement of yours, a clean environment shouldn't be strictly necessary. I don't think it will ever be, the ports tree will always support building a port by just issuing a make in its directory. But: If you're building all your software yourself, you can avoid a lot of unnecessary annoyance by just using a tool like e.g. poudriere.

 

[ljboiler]

portmaster and portupgrade are tools for upgrading already installed ports on the system

portmaster can be used to install something that's not already on the system - I've used it often.

portmaster goes trough all Makefiles to build the depend-list via RUN_DEPENDS

And don't forget there are the BUILD_DEPENDS along with the RUN_DEPENDS when building any of the ports. That list can get rather long.

 

[memreflect]

The ports tree always worked as designed, in any environment -- and in an "unclean" environment, you were from time to time required to solve problems that arose because of that environment.

Poudriere's clean environment is not necessarily compatible with the behavior of the ports tree in its current form. For example, USES=ncurses automatically selects whether to build using devel/ncurses or the base system's ncurses when building a port dependent upon ncurses. The selection is based upon whether devel/ncurses is already installed on the system, which means any jail originally created by Poudriere will never use the ncurses port without a dependency on the ncurses port. One workaround involves modifying the jail directly (or cloning it and creating a separate jail). Another workaround would be to modify the ports tree used by introducing a make variable NCURSES_DEFAULT that can be set using DEFAULT_VERSIONS in an applicable make.conf file, similar to using DEFAULT_VERSIONS+= ssl=libressl to set the SSL library desired. The latter option could be used with Poudriere's "sets" with no need for a completely separate jail, and it would also work for people building on a live system using make, portupgrade, portmaster, etc.

If you're building all your software yourself, you can avoid a lot of unnecessary annoyance by just using a tool like e.g. poudriere.

Despite the long build times for ports of software written in languages like Go, Rust, and Haskell that have package managers already and would benefit from a shared cache between builds of different ports using the same packages, Poudriere is definitely less hassle, not to mention its manpages are very readable compared to portmaster. And if you need to build packages with different make.conf configurations—as one might need to do with different SSL versions, different Python 3 versions, etc.—Poudriere's flexibility in that regard is invaluable.

 

[zirias@]

Poudriere's clean environment is not necessarily compatible with the behavior of the ports tree in its current form. For example, [BGCOLOR=#dee3e7] USES=ncurses[/BGCOLOR] automatically selects whether to build using devel/ncurses or the base system's ncurses when building a port dependent upon ncurses. The selection is based upon whether devel/ncurses is already installed on the system

That's a so-called "automagic dependency", which should be avoided in any case. They happen by accident when building on a live system, but they definitely shouldn't be expected behavior.

Another workaround would be to modify the ports tree used by introducing a make variable NCURSES_DEFAULT that can be set using DEFAULT_VERSIONS in an applicable make.conf file, similar to using [BGCOLOR=#dee3e7] DEFAULT_VERSIONS+= ssl=libressl[/BGCOLOR] to set the SSL library desired.

I wouldn't call that a "workaround" but the only correct solution. Do you know any more examples? I would just assume nobody got around fixing this one yet...

 

[Jose]

Despite the long build times for ports of software written in languages like Go, Rust, and Haskell that have package managers already...

This is not the solution, it's part of the problem. Setting aside for the moment the antisocial "I'm gonna download all my own stuff and keep it in a secret place" approach these language-specific package managers take, what happens when they depend on a C library that some other language also needs? What happens when there's a version of that library already in the base system?

The approach of downloading all dependencies at install time also guarantees that two installs of the same packages are likely to be different if they were installed a few hours apart. Makes troubleshooting nice and simple.

Package management should be provided by the operating system. I'm not interested in your shiny new buzzword-compliant language if it won't play nice with my system's package manager.

 

[memreflect]

This is not the solution, it's part of the problem.

I respectfully disagree. If you can't build software written in a language like C due to a missing dependency, you only have two options:

1. Mail the sysadmin requesting the dependency be installed and hope they fulfill your request. On a personal machine, you can forgo this and just install the dependency yourself via pkg/ports. Of course, if your request is denied, or there is no port for the dependency, you only have one other option:
2. Build and install the dependency yourself. Hopefully it doesn't have its own dependencies that need built, and hopefully it builds without any errors. Otherwise, you need to determine what went wrong, which can take up quite some time that could be spent being productive.

With languages that have language-specific package managers, you can generally bypass both problematic issues. That's not to say there aren't problems, but such problems do tend to be easier to deal with than, say, detecting a recent-enough version in a configure script because there is no associated pkg-config file allowing you to require a version easily.

Setting aside for the moment the antisocial "I'm gonna download all my own stuff and keep it in a secret place" approach these language-specific package managers take,

This isn't antisocial behavior: if you don't have the access rights to install software in a global location and have no way to temporarily gain access (e.g. sudo, doas), it has to be installed somewhere in your HOME or some other location where you have access.

what happens when they depend on a C library that some other language also needs?

It fails to work because C isn't a part of that language's ecosystem and can't be downloaded automatically using that tool. That's the domain of the system's package manager or manual installation in one's HOME since there is no package manager for C (nor should there be; we have "build systems" like Autotools, CMake, Meson, etc. that are used to customize builds out of necessity). It's usually up to the port maintainers/packagers for such languages to deal with include path resolution and linker paths, and this mostly works. Occasionally, you might need to add a path or two. I believe Go and Rust support CFLAGS, CXXFLAGS, LDFLAGS, etc., making it quite simple for them.

Allow me to clarify something: these "package managers" are not intended to replace your system's package manager. Some are little more than package downloaders that automatically build and install the package in some cache with version information about the package stored somewhere. The system package manager and the ports tree serve as a convenient way to install software written in any language while the package management solutions intended solely for use by $LANGUAGE are meant to fetch language-specific software in the event that a sufficient version is not installed.

What happens when there's a version of that library already in the base system?

If such a library is already installed in a known location, and it satisfies the version requirements of whatever software is being built/installed, then it will be used. Otherwise, the source of that library will be downloaded, built, and installed first, using the language's package manager. As an example, cc(1) won't look in /usr/local for headers or libraries by default. If cc acted like the Go compiler, it might try to fetch the dependencies itself, instead of failing to compile, based on some file containing a list of required dependencies. Alternatively, it might fail to compile, and you'd need to use something like ccget $URL to download, build, and install the dependency into a hypothetical "C package cache".

The approach of downloading all dependencies at install time also guarantees that two installs of the same packages are likely to be different if they were installed a few hours apart. Makes troubleshooting nice and simple.

I'm not certain what you're talking about here honestly, so I can't comment.

Package management should be provided by the operating system. I'm not interested in your shiny new buzzword-compliant language if it won't play nice with my system's package manager.

That's a problem for system package/port maintainers, not the programmers creating the software. If there isn't a port for some language-specific package, it's going to need to be downloaded.

audio/spotifyd requires 340 Cargo crates (packages), and audio/spotify-tui requires 219 crates. Out of those 559 crates that will be built, 343 are unique to either port, and 108 are shared, for a total of 451 crates actually required to be built, meaning 23.947% of the required crates are built twice. In the entire 2020Q2 ports tree, 9898 total crates are listed with only 2837 crates actually being unique, and "28.662% of the total number of crates listed are unique" is the same as saying "71.338% of the total number of crates listed are potentially built more than once." That's horribly inefficient. Of course, nobody builds all the ports, except for the people who do.

Poudriere using a clean environment to build ports is obviously a good idea. Maybe this problem is unique to ports that require Cargo for dependencies. Maybe Go ports, Node.js ports requiring www/npm, Ruby ports that use gems, etc. are "less wasteful" compared to Rust ports that require Cargo to download dependencies. But if not, building ports in bulk would certainly benefit from a shared cache.

 

[Mjölnir]

There is no clean solution in an imperfect environment...

 

[Jose]

I respectfully disagree. If you can't build software written in a language like C due to a missing dependency, you only have two options:

1. Mail the sysadmin requesting the dependency be installed and hope they fulfill your request...

This is an organizational problem. You should have root on some dev system, or better, your own virtual environment if you're writing software. You can't write code to solve organizational problems. Inventing your own little package manager to work around your org's stupid policies only creates more problems.

I believe Go and Rust support CFLAGS, CXXFLAGS, LDFLAGS, etc., making it quite simple for them.

I prefer to learn only one package manager, and then I can know instead of guessing, believing, and hoping.

Allow me to clarify something: these "package managers" are not intended to replace your system's package manager. Some are little more than package downloaders that automatically build and install the package in some cache with version information about the package stored somewhere.

How is this not antisocial behavior? I don't want to hunt down the troublesome library in all the little nooks and crannies your idiosyncratic package manager uses. It's always easier to do things your own way than to learn how things are done in order to cooperate with others.

I'm not certain what you're talking about here honestly, so I can't comment.

Jose's package manager (jpm) has a feature that allows you to specify minimum versions for dependencies. You can declare, for example, that your package foo depends on library bar version 2.0 or later. I install package foo and get libbar.so.2.0. An hour later, there's a release of libbar 2.1. You install foo and now you get libbar.so.2.1. This new version of bar exposes a bug in foo. You send me a stack trace. I think you're off your rocker 'cause there's no way I can get that stack trace on my install.

Meanwhile, all of libbar's extensive test suite passes with flying colors. The code for foo has not changed. Welcome to a couple of hours in WTF land.

Edit: And this is a very simple example. Imagine something like this happening 3 layers deep in some package with hundreds of gem crates.

That's a problem for system package/port maintainers, not the programmers creating the software. If there isn't a port for some language-specific package, it's going to need to be downloaded.

This is the crux of the problem. If the programmers creating the software can't be bothered to learn their chosen system's packaging tools, they shouldn't be programmers at all.

audio/spotifyd requires 340 Cargo crates (packages)...

Thanks for doing this legwork. I will continue to avoid Rust and Spotify.

 

[memreflect]

I don't want to hunt down the troublesome library in all the little nooks and crannies your idiosyncratic package manager uses. It's always easier to do things your own way than to learn how things are done in order to cooperate with others.

You're completely right about cooperation, but it's not always possible. Many Cargo crates are tagged as v0.X.Y, meaning their interface is unstable; they're effectively usable beta versions. Individual pieces of software have their own dependencies, and it's better for that software to manage them instead of forcing that burden on maintainers, at least while that software is immature. That's the entire point of the language-specific package managers: facilitating the use of open-source software in a way that simplifies development. I can fetch a specific version of a Go project from GitHub for use in my own software easily, but I can't use pkg, apt, yum/dnf, etc. to do anything like that.

As for bug hunting, it's no different compared to any other language.

Jose's package manager (jpm) has a feature that allows you to specify minimum versions for dependencies. You can declare, for example, that your package foo depends on library bar version 2.0 or later. I install package foo and get libbar.so.2.0. An hour later, there's a release of libbar 2.1. You install foo and now you get libbar.so.2.1. This new version of bar exposes a bug in foo. You send me a stack trace. I think you're off your rocker 'cause there's no way I can get that stack trace on my install.

Meanwhile, all of libbar's extensive test suite passes with flying colors. The code for foo has not changed. Welcome to a couple of hours in WTF land.

I think I understand your point now. You're suggesting that because some other package P updated libbar from v2.0 to v2.1, suddenly foo will rely on libbar v2.1 instead of libbar v2.0. But that's not how it works. You can have multiple versions installed. This may seem wasteful, but the problem you're describing is exactly why there's a reliance on minimum versions. If v2.0 is specified as the minimum version (i.e. >=v2.0), then v2.0 will be used, even if v2.9 is installed. There is no breakage unless you decide to bump your dependency requirements to a newer version. Once you do that, it's your job to figure out what went wrong, if anything.

That's where these language-specific package managers differ from a more traditional system package manager: software shouldn't break just because your system suddenly upgraded a library, but if it does, you should be able to use the older version of the library until you figure out what happened because that's the one that worked. Meanwhile, others are still building using the working code instead of multiple people wasting time hunting a bug down because of a system upgrade that broke the program.

This is the crux of the problem. If the programmers creating the software can't be bothered to learn their chosen system's packaging tools, they shouldn't be programmers at all.

And if that chosen system is the Debian, Fedora, and Arch Linux distributions as well as FreeBSD? Just because I can create system-specific packages/ports for each of those systems, that doesn't change the fact that one or more dependencies I need to build that binary package may not be available as system packages or are even the wrong versions (e.g. maybe there's a bug in v2.1 and v2.1.1 hasn't been released yet). With a language-specific package manager, I can build software with no worries about that because of the version requirements specified, instead of fighting with my development system. In cases where a system-specific package is needed for me to build my software, it's up to me to deal with that when creating the package/port.

Thanks for doing this legwork. I will continue to avoid Rust and Spotify.

At this point, I don't expect to convince you that language-specific package managers are somehow better than any package manager meant for installing packages in a system-wide location, but that was never my goal in the first place. They serve the purpose of dealing with dependency-related problems without the need for a dedicated machine containing the dependencies required, and they are even more useful in the case where you want to add some dependency on package P that was built against libbar v2.1, yet you can only use libbar v2.0 because of a bug in v2.1 or your software. Whereas a system package manager would upgrade to v2.1, your software can continue to rely upon v2.0 while P relies on v2.1. Eventually the bug will be fixed, but until that happens, you're stuck at v2.0.

 

[Mjölnir]

[...] the problem you're describing is exactly why there's a reliance on minimum versions. If v2.0 is specified as the minimum version (i.e. >=v2.0), then v2.0 will be used, even if v2.9 is installed. [...]

Usually the general assumption is that later versions fix bugs of previous versions, thus later versions are used. In the example if minimum version >=2.0 and 2.9 is installed, 2.9 will be used, but 3.0 wouldn't be used because the ABI will likely have changed (else the new versions would be 2.10, 2.11,...). You would have to state minimum version=2.0 to stick on that version.
Other than this minor flaw, I do enjoy your conversation because of the good quality of your arguments (on both sides).

 

[Jose]

...You're suggesting that because some other package P updated libbar from v2.0 to v2.1, suddenly foo will rely on libbar v2.1 instead of libbar v2.0. But that's not how it works. You can have multiple versions installed. This may seem wasteful, but the problem you're describing is exactly why there's a reliance on minimum versions. If v2.0 is specified as the minimum version (i.e. >=v2.0), then v2.0 will be used, even if v2.9 is installed...

No package manager I'm aware of works in this way*. If foo needs exactly bar 2.0 and baz requires 2.1 or later, both can't be installed on the same system. You'd have to link every binary differently to support what you describe. You can kind-of do this with platforms that use a loader, like Java, but then you need hundreds of lines of shell to launch even the simplest executable.

...That's where these language-specific package managers differ from a more traditional system package manager: software shouldn't break just because your system suddenly upgraded a library, but if it does, you should be able to use the older version of the library until you figure out what happened because that's the one that worked. Meanwhile, others are still building using the working code instead of multiple people wasting time hunting a bug down because of a system upgrade that broke the program.

All you're doing is kicking the integration can down the road, and probably making it someone else's problem. Given that integration is one of the messiest and least interesting parts of building software, throwing things over the wall like this is extremely antisocial.

And if that chosen system is the Debian, Fedora, and Arch Linux distributions as well as FreeBSD? Just because I can create system-specific packages/ports for each of those systems, that doesn't change the fact that one or more dependencies I need to build that binary package may not be available as system packages or are even the wrong versions (e.g. maybe there's a bug in v2.1 and v2.1.1 hasn't been released yet). With a language-specific package manager...

If you build something useful and package it for a reasonable platform, support will come. This is one of the great strengths of open source software. Others will help you if you're not too antisocial.

*Gentoo has some limited support for this with "slots". However, slots are hard to maintain, and creating new ones is frowned upon by the Gentoo devs. They're typically only used for things like Php 7.3 vs 7.4, the Python mess, etc. They do come in extremely handy for database upgrades, though. You can have both the old version of Postgresql and the new one installed side-by-side.

 

[garry]

ports-mgmt/synth hasn't had an update in a year but out isn't flagged as "no maintainer" or anything. I used it a few months ago and it worked fine....

Take a look at the source code for synth -- I've seldom seen such clean and beautiful code. Even if developers do prefer to build with the poudriere script (and use jails instead of null mounts to allow building malicious/bad-actor ports) every programmer could benefit from learning a little bit from synth's Ada code. It is really sweet. And I have to add that I've seldom seen any package receive such good support as synth does here. Mention any problem with synth and the author will be show up as if by magic to help...

(Synth is the most straight-forward replacement for portmaster:

synth configure
synth upgrade-system
synth install <port>