On Wed, Jun 14, 2023 at 07:29:57PM +0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Julian Andres Klode (2023-06-14 18:00:42)
> > This allows users to customize their systems and avoid installing recommends
> > they don't want.
>
> I do not see a reasonable cost/benefit ratio here. There is a surprising amount
The topic of "conditional dependencies" comes up once in a while, and
that is basically how this came up as well – as a pipe dream. I was
somewhat surprised Julian would actually go and post it seriously.
The things you usually want to express with those are roughly:
* if X, do not install foo (aka: bar recommends foo for printing, if
machine can't print, don't install it)
* if X do also install foo (e.g. install firefox-l10n-de if firefox
is installed and user wants german language packs)
* make a "clever" choice for virtual package rather than assuming the
"real | virtual" can always list the best 'real' for everyone
(e.g. different reals for different desktop environments)
You have a few options to solve these which mostly differ in who has
control over it:
* (the one proposed first here) let maintainers annotate their
dependencies
* (the second one) let the dependent on package say what it is for
* decouple it entirely from the packages and have e.g. the release team
maintain a sorta hints file for the entire repository
They mostly differ in this regard, as you can express most uses in all
three of them, so lets pick a somewhat real example (not a good one,
I just stumbled over its existence recently) for the last case as the
other two are simple to imagine as homework for the reader:
libdecor-0-0 (client-side window decoration library for Wayland)
Recommends a plugin (virtual: libdecor-0-plugin-1) with a preference for
libdecor-0-plugin-1-cairo. It is not existing yet, but I suppose given
enough interest other desktop frameworks will jump on that train as
well, so lets just pretend there exists others for qt and a few more.
You could do:
1) "foobar Recommends: libdecor-0-plugin-1-cairo <gtk>,
libdecor-0-plugin-1-qt <qt>, libdecor-0-plugin-1-foo <bar>,
libdecor-0-plugin-1-cairo | libdecor-0-plugin-1"
2) "libdecor-0-plugin-1-qt is libdecor-0-plugin-1 for qt" via a
Profiles field, debtags or whatever
3) "if(resolving(libdecor-0-plugin-1) && desktop-environment(qt)) =>
install(libdecor-0-plugin-1-qt)"
(1 is actually written to support multi installed desktop environments,
I left that out of 2 and 3)
1) is a nightmare every time you add a new desktop environment to the
distribution and/or to the plugin set
2) works fine in this case, but god forbid the package maintainer
doesn't agree with the default (compare :any or arch-specific
dependencies in M-A)
3) extremely powerful, but near impossible to implement for anyone who
just wants to dabble in dependencies.
Before you cry too loudly that 1) is silly, lets remember that this
is basically our method of choice for every virtual package at the
moment.
I would like virtual packages in general to be controlled in 3) (aka
a central file who declares which real package is the default for
a virtual package rather than having that duplicated all over the place)
while the l10n packs are probably best handled by the maintainer
themselves in their own metadata (2) with debtags could e.g. kinda work,
except there are probably M-A:any-type kind-of situations so there are
likely situations in which 1) would be nice as an escape hatch).
So I am somewhat convinced, we will end up with all three for slightly
different but related use cases in some distant future – assuming we
don't invent time machines first & do all those nifty time machine
fixes…
> implementation for build profiles. And there is more software handling binary
> packages than software handling source packages.
While I don't disagree, I wonder a bit if we really have that many who
worry about binary dependencies – especially the weak kind – which don't
have support at least somewhat available by already caring about build
profiles (e.g. in libapt, the same code deals with both and for better
or worse a whole lot of our binary-interested toolset is somewhat based
on libapt/python-apt/… while source-interested is mostly bring-your-own
as libapt is traditionally not that interested in it itself).
That is mostly based on M-A more or less silently adding architecture
specific dependencies and not a whole lot of things cared too much.
Or its just because they aren't used a whole lot for reasons.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature