On Thu, 7 Nov 2024 22:29:07 -0500 "Theodore Ts'o" <ty...@mit.edu> wrote:
> On Thu, Nov 07, 2024 at 12:08:22AM -0700, Soren Stoutner wrote: > > On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt > > wrote: > > > Again, this isn't a problem limited to a derivative distribution. > > > I respect that your opinion of how Recommends should work differs > > > from mine. That doesn't change the policy though, and it doesn't > > > change that neglecting or changing the policy's rules in this > > > area will cause and is causing problems to some of Debian's > > > users. Ultimately I don't care exactly how those problems are > > > solved, I just want to solve them. > > > > Let me try to explain what I see as the core of the problem. > > > > First, some background on the three existing categories. > > > > 1. Depends: These are the packages necessary to install and run > > the basic functionality of the package. > > > > 2. Recommends: These are the packages required to enable all the > > features of the package. > > > > 3. Suggests: These are packages that enhance the functionality of > > the package. > > So if we have consensus that these definitions of the categories is > correct, then there shouldn't be any contrversy of whether gwenview is > "wrong"in recommending kamera, which Aaron was objecting to. After > all, there is a button in gwenview that would activate kamera. If > kamera is not installed, then no matter how many time the user mashes > the "kamera" button, Nothing Will Happen. So clearly, thats a > "feature" of gwenview, and kamera should _absolutely_ be a Recommends. > No? > > But let's take a step backwards about why there seems to be so much > passion about this question. Especially when I really don't care all > that much. Part of this is because as far as I'm concerned, my time > is valuble, and storage is _cheap_ so I always configure a huge amount > of storage on my desktops. For example, my root file system is 824 > GiB --- and Kamera is 1 MiB. So as far as I'm concerned, the amount > of time that I've spent reading this e-mail thread is far more > expensive that the storage cost of Kamera. :-) > > So why do we care? If someone is installing in a very > storage-constrained environment --- say, the are creating some > appliance image to be hosted on a VM, or Docker, or a Raspberry Pi --- > then just configure apt to ignore all of the recommends. Someone who > is trying to configure the appliance may need to do a bit more work to > figure out what package are *really* needed, but if they are really so > concerned about minimizing every single byte, then that's probably the > right answer. > > And these days, with the size of most desktop systems, maybe we should > be optimizing for user convenience, and for that use case, just > installing all of the Recommends packages is again, probably the best > choice in terms of making life easy for users, at the minor cost of > paying a bit more for storage. (Reminder: 1TiB of SSD can be as cheap > as $50 USD --- and if you want to super-duper expensive, gold-plated > SSD you have to spend $100 USD. Horrors!) > > So what we seem to be trying to optimize for is this middle ground > where storage is not super-duper constrained, where the user will want > to very carefully consider every single package to decide whether or > not each package should be installed --- and yet storage is *just* > cheap enough that you want to have "the right thing" to happen. The > only problem is that everybody's opinion is going to be different > about what "the right thing would actually be". And until we can have > some kind of AI were you can tell the system what exactly you plan to > use diffoscope for in human language, and have it automatically decide > what packages you need or not, I don't think this problem is really > soluble. > > Fortunately, I also don't think it's all that important that we solve > it. Personally, I think the current set of knobs and defaults are the > right one. The problem isn't mainly storage actually, there are reasons beyond storage why one may wish to keep their package set minimal. I'm tempted to give examples here but almost every example I give ends up being a point of contention, so I think I'll just leave it there. :P At least from my standpoint, and probably from the standpoint of several others, Recommends oftentimes pulls in things that are problematic for whatever reason (causes crashes, introduces wrong artwork, etc.). In the opinions of many other developers, it appears that not all of these "problematic" things can be moved out of Recommends reasonably (and frankly I agree). There are some controls in apt and Debian for dealing with this, but they are *not* sufficient to reasonably avoid issues in all situations (unless reimplementing the Recommends field using a metapackage network is considered reasonable). Elsewhere, someone had the idea of restricting which packages had their recommends installed, giving finer-grained control than --no-install-recommends without requiring a whole lot of work. Soren mentioned they didn't have a particular problem with this kind of solution, and so far I think it's the most promising one at the moment. Hopefully that will let everyone have what they want - Recommends will remain used like they are now, Debian packaging will be unaffected, and users will be able to concisely specify which recommends they want to install and which ones they don't. It won't fix situations where a recommended package is legitimately wrong and should be demoted or moved, but even in those situations workarounds exist, and bugs can be filed. I think that's probably what will work best. Thanks for the good discussion on all of this! Aaron > Regards, > > - Ted >
pgpEa879r42BW.pgp
Description: OpenPGP digital signature
