Re: Dependencies et al (was: Default Debian install harassed me)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Reco wrote:
> Hello, list.
>
> It may seem a thread hijacking (and may be it is), but I feel that the
> discussion of OP's problem has taken a wrong turn. Consider this a my
> attempt to put in on a right track ☺.
>
> So I've been reading this thread, and it got me thinking. I know, it's a
> somewhat strange confession to make (☺), but anyway:
> [...]
> 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'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. The only way out of that then would
be to compile the affected programs from source, so that they can call
his preferred archive solution (assuming said solution can be hooked
into by the affected programs).
>
>
> 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.
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl2bJ+8ACgkQjhHd8xJ5
ooEMWAf/foOa4n+9swQggiZCePT8g5htTVxiXeX1wqVoBGEvU19K3py6ZzOB6zvI
bbol5/AHj+Oi3ShALGtDUegY8FvNgOgjR1jnBD7ONHxu19lrjCC2cDIWdAyUltkp
bCQGE4DnXwgu3Mk+SpeM522GtWD/NeX5cJCSTKpdNp4SjuuoJbkA36ntziI/LbSo
Dc3SxgwkuySYTSxNSbW/g4Kx3dcgKfPVZ5Q1oA7weRLzg+s/F75ZoIfXMX7BWAUh
nnQ48yJIi7MnuxUWwaUehiruDgG4kSgk4S7brmPkvqYDq03pmNM0XsuzN+kq4AYg
UM/s8vn2pQA/Jjkf8pLMrtBLgmnuuQ==
=Kw3I
-----END PGP SIGNATURE-----
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Reply to: