You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult to discover than typical decisions at compile time.

> this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

Define “usual people who compile this package”. In my books those are distro maintainers who indeed should be familiar with options provided by the init system they choose. If you decide to include oddballs who compile everything themselves (Linux from scratch?) then again, yes, they are expected to know a thing or two or dig into options or even code from time to time.

I mean the parent was talking about the source code being a ball of mud and it being difficult to determine what components can be removed without breaking things.

In this case it should be assumed we’re talking about someone who’s compiling systemd and familiar with the source. And yes, these are flags that anyone who builds systemd from source would be familiar with and know how to set.

It’s the same as when you run a configure script and pass —-disable-feature.

So common with open source - flags that once worked are now tangled up with subsequent code/flags and won't even compile if not part of some common configuration. Because its not fun to exhaustively test all combinations, it doesn't get done.

It seems exactly as difficult as with any other stuff written in C. Let's say uWSGI. systemd uses meson, and there's a file listing all the options, and the first match for "resolve" seems to be that flat: https://github.com/systemd/systemd/blob/master/meson_options...

Furthermore, even if you compile it, you don't have to use it. Even if you install it, you don't have to use it. (After all it has 2-3 APIs, one of them is the /etc/resolve.conf symlink, if you instead just put 1.1.1.1 in that file, libc will not go through resolved. And similarly for the other entry points.)

It's possible to accidentally compile, install and have systemd-resolved set up on your computer, but it still seems rare that someone can compile and install systemd, yet not know what they're doing.

> Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

From HHGTTG:

"But the plans were on display …"

"On display? I eventually had to go down to the cellar to find them."

"That's the display department."

"With a flashlight."

"Ah, well, the lights had probably gone."

"So had the stairs."

"But look, you found the notice, didn't you?"

"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'"

This is a config option that you pass when compiling systemd in the same was as --enable-feature in a ./configure script. If you are familiar with the systemd source you would be aware of these options. They’re not hidden.