Re: Dependencies et al (was: Default Debian install harassed me)
On Mon, Oct 07, 2019 at 01:08:04PM -0000, Dan Purgert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
And we both know it does not work this way, although it should.
One could write thousand words in the documentation, explaining
everything in the finest detail possible. But if no one is reading the
documentation - is there a meaning in all this work?
Hence my suggestion. Users are confused already, and it won't get
better. I have no problem filling a wishlist bugreport, but I like to
estimate the possible users' reaction.
> >> > 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.
> ...
> 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
> ...
No, I got you first time. Rather it's my response deviated elsewhere.
I see nothing in those three packages that would qualify as "xyzzy".
Alternatives? No. Mime types registration? No.
About the only common thing about all three packages is that they are
GUI archivers.
I do not question a choice of these three archivers as "lxqt"
dependency. What I do question is the kind of dependency itself.
> 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.
Why, apt certainly can do it. It's just requires the user to package
PeaZip first ☺
Reco
Reply to: