Can you elaborate on what "justified accordingly" means?

Why are new dependency additions a problem?

It should be explained why the new dependency was introduced and what are the benefits.

Why they're a problem? I thought it was obvious, but here are some reasons:

• they increase on-disk footprint
• more code means more (potential) vulnerabilities
• in some cases, new services running by default, meaning larger attack surface, increased CPU and memory usage

It should be explained why the new dependency was introduced and what are the benefits.
Why they're a problem? I thought it was obvious, but here are some reasons:

they increase on-disk footprint

Every update does this regardless of whether it brings in new deps or not. I don't think it's really relevant.

more code means more (potential) vulnerabilities

OK.

in some cases, new services running by default, meaning larger attack surface, increased CPU and memory usage

I've yet to see an update bring in a dependency that starts a new service by default. Do you have a specific example or are you just speaking in generalities?

As for the ticket in general, I tend to default to trusting our maintainers. If they added a dependency it is typically for a good reason. Having some description of that change in the update is a good idea and I'd like to see that happen, so I agree there. I don't view added dependencies as a problem in general though.

Also, when you take into consideration some of the tooling centered around installing Apps (like Gnome Software), you don't even see all the dependencies. Containers and flatpaks also make this opaque. That isn't to say those models are preferred, but they are becoming the more standard way of installing updates. To users used to the app store model, they won't necessarily even understand what "Added dependency on foo for bar" even means.

For example, after one update of adwaita-qt-theme it started to bring 50+ new dependencies...

It should be explained why the new dependency was introduced and what are the benefits.
Why they're a problem? I thought it was obvious, but here are some reasons:
they increase on-disk footprint

Every update does this regardless of whether it brings in new deps or not. I don't think it's really relevant.

Not every update does it. Some projects actually do drop or refactor code to make it smaller. Also, compilers also get better and may produce smaller code.

more code means more (potential) vulnerabilities

OK.

in some cases, new services running by default, meaning larger attack surface, increased CPU and memory usage

I've yet to see an update bring in a dependency that starts a new service by default. Do you have a specific example or are you just speaking in generalities?

I thought about the mock update bringing in a MTA, but it's not started by default, so no, I don't have a specific example.

As for the ticket in general, I tend to default to trusting our maintainers. If they added a dependency it is typically for a good reason. Having some description of that change in the update is a good idea and I'd like to see that happen, so I agree there. I don't view added dependencies as a problem in general though.

Neither do I, as long as they happen in rawhide only. I strongly believe they should be well justified when done in stable branches.

Also, when you take into consideration some of the tooling centered around installing Apps (like Gnome Software), you don't even see all the dependencies.

Yes, Gnome tries to hide away all the stuff that happens under the hood. Whether it's good or bad, it's debatable.

Containers and flatpaks also make this opaque. That isn't to say those models are preferred, but they are becoming the more standard way of installing updates. To users used to the app store model, they won't necessarily even understand what "Added dependency on foo for bar" even means.

I think you give Fedora users too little credit. Also, the app store model is a horrible mess of bundled stuff full of security vulnerabilties. I honestly hope it never becomes the standard way on Linux.

It should be explained why the new dependency was introduced and what are the benefits.
Why they're a problem? I thought it was obvious, but here are some reasons:
they increase on-disk footprint
Every update does this regardless of whether it brings in new deps or not. I don't think it's really relevant.

Not every update does it. Some projects actually do drop or refactor code to make it smaller. Also, compilers also get better and may produce smaller code.

Compilers get better within a stable release and produce smaller code? No they don't. At least not within the Fedora project's method of compiler support.

Projects refactor code to make it smaller within a stable release? Possible, but that usually happens with a rebase to the package not an incremental fix. Then you have to question whether the rebase is necessary in a stable release.

As for the ticket in general, I tend to default to trusting our maintainers. If they added a dependency it is typically for a good reason. Having some description of that change in the update is a good idea and I'd like to see that happen, so I agree there. I don't view added dependencies as a problem in general though.

Neither do I, as long as they happen in rawhide only. I strongly believe they should be well justified when done in stable branches.

That seems to be viewing the ecosystem with intentional blinders on. It's OK to add dependencies in rawhide without documentation as to why they are added? If so, what happens when a user upgrades to a new stable release where all of that change happened? They see a bunch of new packages get installed with no explanation as to why.

And yes, an upgrade to a new release is larger than an update of a package within a release, but the end-user experience you are concerned about is the same. I don't see why you'd require something on a stable release that isn't required in development. Doing that just pushes the problem you're describing to a later point. It doesn't solve it.

Also, when you take into consideration some of the tooling centered around installing Apps (like Gnome Software), you don't even see all the dependencies.

Yes, Gnome tries to hide away all the stuff that happens under the hood. Whether it's good or bad, it's debatable.

Containers and flatpaks also make this opaque. That isn't to say those models are preferred, but they are becoming the more standard way of installing updates. To users used to the app store model, they won't necessarily even understand what "Added dependency on foo for bar" even means.

I think you give Fedora users too little credit. Also, the app store model is a horrible mess of bundled stuff full of security vulnerabilties. I honestly hope it never becomes the standard way on Linux.

I'm not giving Fedora users too little credit. I'm describing a subset of the target audience that we are going after. Presenting them with a bunch more information is possible. Some may learn from it. Most will likely just click whatever gets the thing they want to install/update actually done.

As to whether app-store/flatpak/containers are the right way to go, that's beyond the scope of this ticket.

It should be explained why the new dependency was introduced and what are the benefits. Why they're a problem? I thought it was obvious, but here are some reasons:
* they increase on-disk footprint

Every update does this regardless of whether it brings in new deps or not. I don't think it's really relevant.

Not every update does it. Some projects actually do drop or refactor code to make it smaller. Also, compilers also get better and may produce smaller code.

Compilers get better within a stable release and produce smaller code? No they don't. At least not within the Fedora project's method of compiler support.

I don't have a specific example (gcc changelogs for minor releases are difficult to find), but it's not impossible that a bug fix in a stable compiler branch causes smaller object sizes.

Projects refactor code to make it smaller within a stable release? Possible, but that usually happens with a rebase to the package not an incremental fix. Then you have to question whether the rebase is necessary in a stable release.

True.

Still, an update that adds a new dependency usually adds far more code than an update that doesn't. Also, all of the packages I mentioned in the ticket were, in fact, rebased during their Fedora release lifetime and added new dependencies which were not mentioned anywhere in most cases.

As for the ticket in general, I tend to default to trusting our maintainers. If they added a dependency it is typically for a good reason. Having some description of that change in the update is a good idea and I'd like to see that happen, so I agree there. I don't view added dependencies as a problem in general though.

Neither do I, as long as they happen in rawhide only. I strongly believe they should be well justified when done in stable branches.

That seems to be viewing the ecosystem with intentional blinders on. It's OK to add dependencies in rawhide without documentation as to why they are added?

I never said that it's fine to do it without any documentation.

If so, what happens when a user upgrades to a new stable release where all of that change happened? They see a bunch of new packages get installed with no explanation as to why.

That's what Fedora Release Notes and package changelogs are for.

And yes, an upgrade to a new release is larger than an update of a package within a release, but the end-user experience you are concerned about is the same.

I'm not sure I understand the above sentence.

I don't see why you'd require something on a stable release that isn't required in development. Doing that just pushes the problem you're describing to a later point. It doesn't solve it.

As I said, I don't, in general. I just meant that introducing new dependencies in a stable Fedora release should have a higher bar than in rawhide.

Also, when you take into consideration some of the tooling centered around installing Apps (like Gnome Software), you don't even see all the dependencies.

Yes, Gnome tries to hide away all the stuff that happens under the hood. Whether it's good or bad, it's debatable.

Containers and flatpaks also make this opaque. That isn't to say those models are preferred, but they are becoming the more standard way of installing updates. To users used to the app store model, they won't necessarily even understand what "Added dependency on foo for bar" even means.

I think you give Fedora users too little credit. Also, the app store model is a horrible mess of bundled stuff full of security vulnerabilties. I honestly hope it never becomes the standard way on Linux.

I'm not giving Fedora users too little credit. I'm describing a subset of the target audience that we are going after. Presenting them with a bunch more information is possible. Some may learn from it. Most will likely just click whatever gets the thing they want to install/update actually done.

Who's "we"? The Fedora Workstation WG? If you don't want to clutter update notes with information about new dependencies then I'm fine with mandating them in the package changelogs, but they should be documented somewhere easy to find, so that people don't have to search far and wide for an explanation why they suddenly have to install 1 or 20 or 50 additional packages with another dnf update. In the app-store/flatpak distribution model, even the information about new dependencies is hidden from users, which I firmly believe is a bad thing.

PS. I'd appreciate it if you took care to preserve quoting.

Another example from today: installer image bloat. See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BVUZWJYW2UVO53EZ2G2ALAQPU5PLDJZR/ .

Should we discuss this in a meeting? Or perhaps re-new discussion on the devel list and see if we can reach any consensus there?