Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?
Hi, Am Thu, Nov 07, 2024 at 11:41:28AM +0100 schrieb Guillem Jover: > Ah I assumed the sources were being taken from pypi, if they are taken > from GitHub, then that explains yes. Perhaps using > https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan > is happy with that one), would solve that problem? (And if it does, > then perhaps python packages should be progressively transitioned to > use pypi URLs to avoid this kind of problem?) I have *not* inspected the situation personally. However, you might want to check the difference between the PyPI tarball and the tarball from Github. In lots of cases these are different and the maintainer might have picked Github for a reason (which is actually the recommendation I've read several times on the Debian Python list). Common cases are missing test suite inside PyPI tarball but maybe other things as well. > But I'm thinking that, perhaps the best option is to ask upstream > directly, whether they are going to release a 2.1.x release soon, or > if they could do that now, and/or whether they could perhaps > remove/rename the git tag perhaps (with the implied issues with messing > with history and git tags being sticky on cloned repos)? As I assume > other downstreams might be in the same/similar situation? Sounds sensible - otherwise I'd probably go with the override proposed by Colin. Kind regards Andreas. -- https://fam-tille.de
Re: RFC: "Recommended bloat", and how to possibly fix ito
On 06/11/2024 19:20, Bill Allombert wrote: > Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : >> Hello, and thanks for your time. >> >> I've been a Debian user and contributor for a while, and have noticed a >> rather frustrating issue that I'm interested in potentially >> contributing code to fix. The issue is what I call "Recommended bloat", >> which in short is what happens when you install a package with all of >> its recommended packages, and end up with a whole lot of stuff installed >> that you don't want and that the package you actually wanted probably >> didn't even need. > > A proposal I made was an option for apt to handle Recommends non > recursively. > That is if A Recommends B and B Recommends C, > apt-get install A --no-transitive-recommends > would install B but not C. This, please! As a user, when I choose to install a package, I am likely to have a reasonable idea of what that package's recommendations do and whether I need them. However, for transitive recommendations, it is unlikely that I will know whether I need those packages. If they in turn have lots of further dependencies then I will probably not install them and take the risk of unwanted breakage to my system. If the top level package that I originally did want needs those transitive recommendations it should recommend them itself, rather than relying on recommendations further down the dependency chain. It would also be helpful if more package descriptions could explain why recommended and suggested packages are needed or helpful and what functionality they provide that would be lost if they were not installed. (Many already do this.) Thanks, Roger PS. I use aptitude, so I can interactively browse through the lists of recommendations, but it's still hard work and it can be a long list of very obscure packages. Do any of the GUI package managers show a graphical dependency tree? That might be really helpful to understand the package relationships and visualise the consequences of various actions. PPS. And the moon on a stick too, please!
Re: RFC: "Recommended bloat", and how to possibly fix ito
On Thursday, November 7, 2024 12:53:27 PM MST Roger Lynn wrote: > On 06/11/2024 19:20, Bill Allombert wrote: > > Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : > >> Hello, and thanks for your time. > >> > >> I've been a Debian user and contributor for a while, and have noticed a > >> rather frustrating issue that I'm interested in potentially > >> contributing code to fix. The issue is what I call "Recommended bloat", > >> which in short is what happens when you install a package with all of > >> its recommended packages, and end up with a whole lot of stuff installed > >> that you don't want and that the package you actually wanted probably > >> didn't even need. > > > > A proposal I made was an option for apt to handle Recommends non > > recursively. > > That is if A Recommends B and B Recommends C, > > apt-get install A --no-transitive-recommends > > would install B but not C. > > This, please! > I should have noted previously (I apologize for not doing so) that the objections I have voiced to some of the proposals do not apply to this proposal. If having this type of option would be helpful (and if the maintainers of apt don't have objections to someone implementing this) than I also do have any objections as it doesn't cause any extra work for package maintainers in general and it doesn't change the way Recommends works for people who chose not to use this argument. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: RFC: "Recommended bloat", and how to possibly fix it
On Wed, 06 Nov 2024 13:08:07 -0600, Aaron Rainbolt wrote: > Then again, > given that policy is clear about how Recommends ought to be used and > it's pretty clear that there are packages that just don't use it right, I'm sorry but I have to disagree here; it's "pretty clear" for you but I believe that there is no such thing as an absolute (nature|god|policy)-given truth; some people may think that the usage of Recommends is more or less correct, others my think that it's more or less incorrect but all we have is a hopefully respectful way to find a temporary consensus. (Why do I write such philsophical mails? Because I'm a bit concerned how often people confuse their perception with some kind of "reality"; and I had the hunch that this thread might also partially take this direction …) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: RFC: "Recommended bloat", and how to possibly fix ito
On Thu, 7 Nov 2024 19:53:27 + Roger Lynn wrote: > On 06/11/2024 19:20, Bill Allombert wrote: > > Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : > >> Hello, and thanks for your time. > >> > >> I've been a Debian user and contributor for a while, and have > >> noticed a rather frustrating issue that I'm interested in > >> potentially contributing code to fix. The issue is what I call > >> "Recommended bloat", which in short is what happens when you > >> install a package with all of its recommended packages, and end up > >> with a whole lot of stuff installed that you don't want and that > >> the package you actually wanted probably didn't even need. > > > > A proposal I made was an option for apt to handle Recommends non > > recursively. > > That is if A Recommends B and B Recommends C, > > apt-get install A --no-transitive-recommends > > would install B but not C. > > This, please! > > As a user, when I choose to install a package, I am likely to have a > reasonable idea of what that package's recommendations do and whether > I need them. However, for transitive recommendations, it is unlikely > that I will know whether I need those packages. If they in turn have > lots of further dependencies then I will probably not install them > and take the risk of unwanted breakage to my system. If the top level > package that I originally did want needs those transitive > recommendations it should recommend them itself, rather than relying > on recommendations further down the dependency chain. One issue with this is that it doesn't really work if you're dealing with metapackages that in turn reference other metapackages. You end up with the "lower" metapackages installed but all of their recommends missing. Making it possible to tune the number of "levels" apt digs would make something like this more useful, but it's still possible for there to be a "lopsided" network of metapackages, where installing recommends to level N results in a metapackage's recommends being omitted, but installing recommends to level N+1 results in a non-metapackage's recommends being installed. However, this isn't that hard to rectify - rather than specifying the depth at which apt should stop installing recommends, one can specify the packages in the dependency tree from which apt should install recommends from. I.e., to replicate --no-transitive-recommends, one would do `sudo apt install package --only-install-recommends-from=package` (please someone pick a better name for this switch). If you're installing a complex metapackage network, you can just specify all the metapackages you want to allow recommends from, i.e. `sudo apt install metapackage --only-install-recommends-from=metapackage,submetapackage1,...` This could then be used in combination with per-install package blacklisting (i.e., `sudo apt install gwenview+ kamera-`) to control recommends very easily and without much effort. As for Kicksecure, it would solve the problems we're running into perfectly, since we'd be able to use recommends in our metapackages and get the advantages of skipping them for normal packages. No changes needed to Debian policy. No changes needed to debian/control. Just modifying apt is enough to begin with, and might even be enough in the long run. This wouldn't fix the issue of packages having too much in their Recommends, but that can be handled with bug reports. Aaron > It would also be helpful if more package descriptions could explain > why recommended and suggested packages are needed or helpful and what > functionality they provide that would be lost if they were not > installed. (Many already do this.) > > Thanks, > > Roger > > PS. I use aptitude, so I can interactively browse through the lists of > recommendations, but it's still hard work and it can be a long list > of very obscure packages. Do any of the GUI package managers show a > graphical dependency tree? That might be really helpful to understand > the package relationships and visualise the consequences of various > actions. > > PPS. And the moon on a stick too, please! > pgpVQPIkiT_dZ.pgp Description: OpenPGP digital signature
Re: RFC: "Recommended bloat", and how to possibly fix it
On Thu, 07 Nov 2024 00:08:22 -0700, Soren Stoutner wrote: > Some packages are clearly in Depends, Recommends, or Suggests. Others might > be right > on the line between two of the categories. In these cases, a maintainer has > to make a > judgement call. If a user thinks they have got it wrong, they are welcome to > submit a bug > report explaining why they think it should be in the other category. This paragraph sums up my thoughts on this topic pretty well, thanks. The distinction between Depends, Recommends or Suggests is not a true/false thing; this is not a question of mathematics or science but always a judgement call. Adding another category won't solve anything IMO but only extend the sometimes blurry area. Clarifying policy may or may not help, in the end there will always be uncertainties, clarifications, bug reports, and the common effort to find the best solution for most users. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: RFC: "Recommended bloat", and how to possibly fix it
On 07/11/2024 04:12, Aaron Rainbolt wrote: just to get around problematic recommends in Debian's packages. What about having a way to configure the packaging tools you use to only consider a whitelist (with pattern match, pin-style) of package Recommends? This way you could use your metapackages Recommends while ignoring others. One major issue I see with your initial proposal is that if there is already some room for interpretation with the current fields, adding a new field is likely to make things even worse in terms of compliance as there will still be room for interpretation (or misuse) with now two fields with slightly tighter definitions and some significant overlap. In short this is a case of "now you have two problems". -- Julien Plissonneau Duquène
Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?
On Thu, Nov 07, 2024 at 11:41:28AM +0100, Guillem Jover wrote: > On Thu, 2024-11-07 at 02:01:49 +, Colin Watson wrote: > > I'd initially misread it as being just a day or two after the yanked > > version, but you're right, it was months later. I suspect it was simply > > uscan - it's using the GitHub tags rather than looking at PyPI, and the > > tag was never removed, so it's hard to see how it could have known any > > better. > > > > This does leave the question of how to hide that version from uscan in > > the future, since uscan doesn't make it easy to ignore specific upstream > > versions and I'd prefer to avoid using opaque regex constructions to do > > it. My best idea is to use uversionmangle to turn 2.1.0 into something > > like 2.0.8~pre1, but is there a better idiom? > > Ah I assumed the sources were being taken from pypi, if they are taken > from GitHub, then that explains yes. Perhaps using > https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan > is happy with that one), would solve that problem? (And if it does, > then perhaps python packages should be progressively transitioned to > use pypi URLs to avoid this kind of problem?) Some do, but it can't be done systematically: if we get the orig.tar from PyPI then it's the "sdist", which is built from the upstream repository, but Python's build tooling unfortunately means it's a bit easier than ideal for the sdist to be accidentally lacking some files, such as documentation or tests. Examples from a quick look in my browser history: https://github.com/RKrahl/pytest-dependency/pull/79 https://github.com/pgjones/quart-trio/pull/19 https://github.com/jendrikseipp/vulture/pull/368 > But I'm thinking that, perhaps the best option is to ask upstream > directly, whether they are going to release a 2.1.x release soon, or > if they could do that now, and/or whether they could perhaps > remove/rename the git tag perhaps (with the implied issues with messing > with history and git tags being sticky on cloned repos)? As I assume > other downstreams might be in the same/similar situation? Indeed. I've filed https://github.com/explosion/catalogue/issues/74 asking if they're willing to help out here. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?
Hi! On Thu, 2024-11-07 at 02:01:49 +, Colin Watson wrote: > On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote: > > Given that I assume the current (non-retracted) upstream version is > > going to be close to surpass the retracted one, I'd go for the +really > > hack. In this case invalidating relationships for external > > dependencies would not seem like a big issue, because it looks like > > the yanked version is the only one that has ever been in Debian, but > > it avoids the ugliness and confusion of epochs (people tend to forget > > to add the epoch in relationships for example) and its stickiness, > > going forward. > > I don't really have any information on whether upstream plans a 2.1.1 or > similar, but it's true it might well happen. Right, see below… > > The other question that comes to mind is why the yanked version was > > uploaded, as from that issue above it seems at that time it should > > have already been marked as yanked. Perhaps we have some automated > > tool that does not honor the yanked markings, which might deserve a bug > > report? Andreas do you recall what tool or process you used for that? > > I'd initially misread it as being just a day or two after the yanked > version, but you're right, it was months later. I suspect it was simply > uscan - it's using the GitHub tags rather than looking at PyPI, and the > tag was never removed, so it's hard to see how it could have known any > better. > > This does leave the question of how to hide that version from uscan in > the future, since uscan doesn't make it easy to ignore specific upstream > versions and I'd prefer to avoid using opaque regex constructions to do > it. My best idea is to use uversionmangle to turn 2.1.0 into something > like 2.0.8~pre1, but is there a better idiom? Ah I assumed the sources were being taken from pypi, if they are taken from GitHub, then that explains yes. Perhaps using https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan is happy with that one), would solve that problem? (And if it does, then perhaps python packages should be progressively transitioned to use pypi URLs to avoid this kind of problem?) But I'm thinking that, perhaps the best option is to ask upstream directly, whether they are going to release a 2.1.x release soon, or if they could do that now, and/or whether they could perhaps remove/rename the git tag perhaps (with the implied issues with messing with history and git tags being sticky on cloned repos)? As I assume other downstreams might be in the same/similar situation? Thanks, Guillem
Bug#1086975: ITP: feather-wallet -- Small and fast Monero desktop wallet
Package: wnpp Severity: wishlist Owner: Soren Stoutner X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: feather-wallet Version : 2.7.0 Upstream Contact: The Monero Project * URL : https://github.com/feather-wallet/feather * License : BSD Programming Lang: C, C++, Python Description : Light-weight, GUI Monero desktop wallet Feather is a free Monero desktop wallet written in C++ with the Qt framework. As contrasted with a typical Monero wallet, Feather does not need to have a copy of the entire Monero blockchain installed locally, which requires a lot of space, but rather connects to an on-line node of servers and queries their copy of the blockchain. This makes Feather small and fast. Feather is beginner friendly, but also caters to advanced Monero users by providing a feature set that is on par with the official CLI. It ships with sane defaults that suit most users, but can also be configured for high or uncommon threat models. . Monero (XMR) is an open-source cryptocurrency that focuses on privacy and decentralization. It aims to improve on existing cryptocurrency design by obscuring sender, recipient and amount of every transaction. There currently isn't a Monero desktop wallet (GUI) packaged in Debian, althouth there are packages for other software relating to Monero, including `monero`, which is a CLI client and `xmrig`, which can be used for mining Monero. I plan to maintain Feather under the Debian Cryptocoin team umbrella.
Re: RFC: "Recommended bloat", and how to possibly fix it
Colin Watson left as an exercise for the reader: > (https://peps.python.org/pep-0508/#extras): effectively groups of > additional dependencies to enable some kind of feature that you can opt > into if you need that feature, rather than having to pick from an > undifferentiated pile of Recommends, or do things like devscripts does the "undifferentiated" feels like it's doing some lifting here. arch's yay (and presumably other tools in the pacman family) shows a short justification for each optdepends[0] entry (when such information is provided). it would require not just control file changes but also UI work, of course. --nick [0] https://man.archlinux.org/man/PKGBUILD.5 -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: RFC: "Recommended bloat", and how to possibly fix it
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. Regards, - Ted
Re: RFC: "Recommended bloat", and how to possibly fix it
On Thu, 7 Nov 2024 22:29:07 -0500 "Theodore Ts'o" 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 inst
Re: RFC: "Recommended bloat", and how to possibly fix it
On 2024-11-08 00:17, gregor herrmann wrote: The distinction between Depends, Recommends or Suggests is not a true/false thing; this is not a question of mathematics or science but always a judgement call. Adding another category won't solve anything IMO but only extend the sometimes blurry area. Clarifying policy may or may not help, in the end there will always be uncertainties, clarifications, bug reports, and the common effort to find the best solution for most users. And, IMO more importantly, there is a question of why this problem needs solving. What are the underlying pain points people have. If a package that is pulled in by a Recommends breaks your local configuration (the example with the terminal emulator getting hijacked), that is indeed a problem - and that should be fixed regardless. Otherwise it is maybe a bit wasteful in terms of bandwidth (initial download and updates) and disk space - but installing yet another package should not otherwise hurt the user. In general the requirements imposed here are not outrageous and maybe in the rare cases where they are bug reports might be useful. If you are building a derivative and are concerned about recommends pulling in "random" things: Sure, but arguably you would want to control your dependencies more strongly anyway - be it for support load, or other constraints. Having an allowlist of packages that you compare your package set against that you review for changes might help. And then you just go and prune what isn't on the list. Or maybe have a metapackage that conflicts against unwanted software. For others it might be about more easily surfacing individual feature sets to the user (like tasksel, but for software groups) where metapackages might be a bit too messy. But then that's a different ask from a weak-depends, as well. Kind regards Philipp Kern
Re: RFC: "Recommended bloat", and how to possibly fix ito
* Aaron Rainbolt [2024-11-08 00:21]: [...] > However, this isn't that hard to rectify - rather than specifying the > depth at which apt should stop installing recommends, one can specify > the packages in the dependency tree from which apt should install > recommends from. I.e., to replicate --no-transitive-recommends, one > would do > `sudo apt install package --only-install-recommends-from=package` > (please someone pick a better name for this switch). If you're > installing a complex metapackage network, you can just specify all the > metapackages you want to allow recommends from, i.e. > `sudo apt install metapackage > --only-install-recommends-from=metapackage,submetapackage1,...` [...] I personally would consider a "apt install-recs", analogous to "apt build-dep", quite useful. That would require multiple steps instead of a single command, but allow installing the recommends for a specific package at any later time, which is also useful when they have changed over time or you change your mind about installing them. - Fay
Re: RFC: "Recommended bloat", and how to possibly fix ito
On Fri, 8 Nov 2024 03:47:05 +0100, Fay Stegerman wrote: >I personally would consider a "apt install-recs", analogous to "apt build-dep", >quite useful. That would require multiple steps instead of a single command, >but allow installing the recommends for a specific package at any later time, >which is also useful when they have changed over time or you change your mind >about installing them. Agreed! And I would also love the possibility to directly paste a package list from apt show's output into apt install without having to remove the commas. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: RFC: "Recommended bloat", and how to possibly fix ito
On Fri, Nov 08, 2024 at 08:20:46AM +0100, IOhannes m zmölnig wrote: > Am 8. November 2024 06:42:25 MEZ schrieb Marc Haber > : > >Agreed! And I would also love the possibility to directly paste a > >package list from apt show's output into apt install without having to > >remove the commas. > > > > > This! apt satisfy -- WBR, wRAR signature.asc Description: PGP signature
Re: RFC: "Recommended bloat", and how to possibly fix ito
Am 8. November 2024 06:42:25 MEZ schrieb Marc Haber : >Agreed! And I would also love the possibility to directly paste a >package list from apt show's output into apt install without having to >remove the commas. > This! mfh.her.fsr IOhannes
