Re: Dependencies et al (was: Default Debian install harassed me)
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
Reply to: