[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependencies et al (was: Default Debian install harassed me)

Hash: SHA256

Reco wrote:
> 	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.

So then the education needs to be fixed, not the material.  I mean, at
one point in our lives, we were all confused by what we'd consider
"simple mathematics" nowadays.

>> 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.

Fair enough.

>> > 4) Metapackages tend to have restrictive dependencies.
>> >
> [...]
>> 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".

I think I worded the response here poorly.  

As I understand things - "lxqt" requires one of three options for an "X
based compression tool" (presumably as a requirement of a "complete(tm)
DE" or similar line of thought).  The package maintainer has determined
that there are three that fit the bill -> xarchiver(default), ark, or
engrampa. Of those, I assume that all three provide the necessary
"provides xyzzy" information (e.g. how installing postfix or exim
"provides" /usr/sbin/sendmail) to allow generic graphical tools to hook
against them without needing to have compile-time options set.

Therefore, we end up with a few things we can take away:

  1. Three options is all the package maintainer can keep track of (in
      addition to everything else).
  2. Three options was deemed "enough" by the package maintainer.
  3. The other options (e.g. pz7ip) do not provide the aforementioned 
      "hooks" required by something else.
  4. The other options (e.g. p7zip) are actually part of non-free and 
      I missed that somewhere :)

In either event, I think one of the mails mentioned wanting to use
peaZip, which isn't even available in the repos, so it doesn't matter
anyway; as APT would never be able to do dependency resolution.



|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Reply to: