Remix.run Logo
avhception 6 days ago

While I have a lot of respect for the effort that goes into Debian, I always disliked this kind of "maximalism" from the package manager. Oh, the user wants "foo"? Let's install every software that might be even remotely useful somehow in combination with foo! Oh there is a network daemon in there? Fantastic, let's start it immediately!

I know that there is a flag to disable the installation for "recommended" packages. I just think the default is a disservice here.

bayindirh 6 days ago | parent | next [-]

I'll politely disagree.

First of all, "Recommends" is reserved for packages which enhance the functionality of the package you're installing. Without these the package will not break, but some very useful functionality might be disabled.

The package-class you're talking about is "suggests", IOW, "these packages might also be useful for you, wanna look?" section. These are not installed by default already.

On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.

There's a tension. Minimalism vs. user utility. Somebody told in Debian 13 release comments that "Debian will never be a end-user friendly distro". Now, you're saying that packages shouldn't install recommends by default.

What should Debian be? "An IKEAesque DIY distro", or "A more user friendly, yet very stable and vanilla distro". I vote for the latter, personally. Plus, as I told before, advanced users are free to use what they want to change.

If you want to change the default, the configuration files are at /etc/apt/conf.d/. If you want to disable feature for once, it's --no-install-recommends.

avhception 6 days ago | parent | next [-]

Well, as a user of one of the more "IKEAesque" distros, I guess I have made my choice ;)

And that's perfectly fine, it just means I don't align with Debian on this one. And that freedom is what Linux is all about, I guess. So it seems it's working as intended :)

Edit: And I totally get that users might often want that kind of maximalism. It's just not for me. Although starting network daemons by default might sometimes be a bridge too far, or the case described in the article here.

bayindirh 6 days ago | parent [-]

While I'll argue that Debian's network daemons come with very sane defaults and an accompanying AppArmor profile to prevent both network disruptions and attack surface increases, I'm certainly not with the developer of StarDict. That thing smells malicious.

...and this is what Debian Testing is actually for. To catch these types of issues.

Of course, people are free to select what they resonates with them. I'm not against more DIY distributions (I'm also contemplating using a LFS VM to explore things even further, but time is an issue), and I'm not against your personal choices. I just wanted to note the tension, and share my observations about Debian.

account42 6 days ago | parent | prev [-]

I agree that recommends makes sense but this is a bullshit argument:

> On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.

You can't expect the average user to understand the entire dependency tree and read the description of dozens of random packages that the average program pulls in. RTFM is not a valid excuse for bad defaults.

bayindirh 6 days ago | parent [-]

I don't expect average user to read an entire dependency tree. However, apt and aptitude does a relatively good job of explaining their actions' reasons.

Let me rephrase:

    1. Installation of recommended packages is a good default for the average user, because it provides functionality they expect.
    2. If the user is not happy with what's happening, changing defaults are not hard.
IOW, if you don't like how your system behaves, read the documents. Otherwise, I argue, current defaults is good for the benefit of the newcomer and average Linux user. If you are at a point where you are caring which package is doing what, you're leaving "average user / beginner" realm.

In the case of StarDict, as I noted elsewhere, I think the developer's answer is fishy, or ill-informed at least.

ioasuncvinvaer 5 days ago | parent [-]

Why does "caring what a package does" mean that someone is no longer a beginner?

All the people I know care what their software does.

bayindirh 5 days ago | parent [-]

From my experience, newbie users are generally more interested in the end result: Their intended packages are working, and what that package is doing. They are not yet interested in all the libraries required and whatnot.

As they get familiar with their systems, they get interested in what makes the particular package or software tick. Then, the digging starts. At that point they are already pretty proficient with their package managers, and start to learn their systems inside out. At that point they're not beginners since they can do targeted tinkering.

Except very rare circumstances, I didn't see anyone to dive to the deep end directly.

ioasuncvinvaer 5 days ago | parent [-]

I guess sou just have a weird definition of "what a software does" means. Because to it is exactly about the end product.

bayindirh 5 days ago | parent [-]

If wondering about why some libraries are installed as a part of an application, and having a desire to learn the function of a library in that context is a "weird" definition of "wondering about what software does", then yes.

Libraries does matter. =)

ethan_smith 5 days ago | parent | prev | next [-]

This is a classic tension between convenience and security - Debian's "recommends" defaults were designed for a pre-cloud era when network connectivity wasn't assumed and local functionality was prioritized over potential security boundaries.

barosl 5 days ago | parent | prev | next [-]

Actually the default value of `APT::Install-Recommends` had been false, and it was changed to true in Debian 6.0 Squeeze (2011-02-06). I didn't like the change at the time because my Debian and Ubuntu systems suddenly installed more packages by default. However, now that I think of, the distinction of recommended packages and suggested packages was blurry before the change, because both were opt-in. Auto-installing recommended packages, while allowing the user to opt out is a better default I guess. But I still turn off auto-installation of recommended packages in the systems I manage.

tremon 5 days ago | parent | prev | next [-]

I don't have a problem with --install-recommends being the default. I think it's a fine distinction to have Recommends be "most of our users will want these" and "this package provides some niche feature that most users won't need".

However, like you, I do have a problem with maintainers abusing the Recommends: field to further their own world domination plans. There is no valid reason that installing an archive tool should mandate a specific init system (looking at you, file-roller and gnome team in general).

account42 6 days ago | parent | prev | next [-]

The other extreme where you are missing expected functionality because it's optional isn't any better. The problem is not that recommended dependencies are installed by default, it's that package recommendations should perhaps be more conservative. Note that Debian already differentiates between recommended dependencies (which most users should want) and suggested dependencies (related functionality or enhancements that are not relevant for every user).

rfoo 6 days ago | parent | prev [-]

For me it's my most used super long command line flag.

For a brief moment `--break-system-packages` surpassed it, then I discovered `pip` accepts abbrev flags so `--br` is enough, and sounds like bruh.

IshKebab 6 days ago | parent [-]

> --break-system-packages

You can avoid that clusterfuck using `uv tool install`. E.g. `uv tool install pre-commit`.

zahlman 5 days ago | parent [-]

It's also not hard to just manage a damn virtual environment yourself.

IshKebab 5 days ago | parent [-]

That doesn't really work for tools that you want to be available everywhere.