Hi. On Mon, Oct 07, 2019 at 11:56:33AM -0000, Dan Purgert wrote: > > 3) Synaptic did not provide a user a meaningful choice. > > [...] > > I'm not saying that Synaptic should be transformed to aptitude (which is > > famous for its multi-choice resolver), we have one aptitude already, > > please leave it this way. But showing the *reason* of such replacement, > > i.e. "lxqt package demands that you will have some archiver installed" > > would be a definite step in right direction. > > I don't think anything needs to be done here -- the whole idea of > (meta)packages is that you give up some choice for the benefits of not > having to deal with dependency hell.
I disagree. The parent thread shows that at least some of the users are confused by metapackages. > I'm not sure what "lxqt" needs across the board, but I imagine that > since it wants one or the other archive program, there are one or more > other packages built against them. Does not seem to be the case. One of "lxqt"'s dependencies, "ark" is a KDE archive utility. Or so is says in the description. Another one, "enrgampa", comes from MATE. "lxqt" is a typical metapackage, listing some totally unrelated programs with dependencies that could fit a certain role, and said programs do not come with LXQT. > > 4) Metapackages tend to have restrictive dependencies. > > > > The whole fuss is about the contents of the Depends field of "lxqt". > > Last, but not least - is there a meaningful reason to use Depends > > instead of Recommends in metapackages such as "lxqt"? Barring the > > "gnome" package, I know the answer for it. > > Does it really matter though? > I mean, there's a basic set of "X-core-utils" that I think can be > agreed on as required for a full-featured DE. One of those being > something that can handle archives. In the case of the original "problem" - yes it does. Installing a metapackage with Recommends only would still pull the same dependencies (by default, that is), but removing one of said dependencies would not force another one on a user. Of course it leaves the user without a program to handle archives (from user's POV), but it may be the desired outcome. This way flexibility is gained, nothing is lost, user is saved from the confusion. Am I missing something? > According to the "similar packages" lists of the three options in the > Bullseye package listings, it looks like there are a handful of other > alternatives that the package maintainer "might" have chosen as > alternates / in addition to the three that he did. But, then I don't > know enough about those packages (e.g. file-roller, or p7zip) to say > whether they'd actually work -- that is, whether they provide the > ability for the other "default" applications to hook into / be compiled > against. That's somewhat different problem. Certain applications (terminal emulators, browsers to name a few) provide a virtual packages such as x-terminal-emulator or x-www-browser to save the trouble of listing all the possible alternatives in a package dependencies. Reduces the amount of bugs if some package leaves the archive too. But I see no virtual package that means "I'm an archive utility with GUI". Reco
