Quoting Simon Richter (2023-06-16 16:32:19)
> On 16.06.23 22:29, David Kalnischkies wrote:
> > 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)
> All of these could be done with "negative" packages, even today.
everybody remember that Debian dependencies are expressive enough to solve
Sudoku puzzles:
curl https://mister-muffin.de/p/5hvD.py > dosesudoku.py
curl https://mister-muffin.de/p/9hvG.py > debsudoku.py
curl https://mister-muffin.de/p/4pcJ.txt > ksudokuboard.xml
python debsudoku.py --mode=print ksudokuboard.xml
python debsudoku.py --mode=conflicts ksudokuboard.xml > Packages
dose-distcheck --explain --successes --checkonly puzzle deb://Packages | python dosesudoku.py
so in the end this is more a question of convenience and how many meta-packages
we are fine with creating to solve a problem.
> Recommends: foo-print | no-printing
>
> Recommends: firefox-l10n-de | no-task-german
>
> Recommends: gnome-terminal | no-gnome,
> kde-terminal | no-kde,
> lxde-terminal | no-lxde
>
> The reason we don't do that is that it creates a lot of bloat in the
> package list and all of these would show up in the package managers.
>
> So, having a less annoying way to do negation would solve most of these
> problems -- are there any it doesn't solve?
One does not necessarily need to bloat the Packages list with these. Suppose
that we had the install profiles suggested by Julian. Now there needs to be a
way for the user or admin to set the activated (or deactivated) profiles for
the current system. Intuitively, we imagine that such a tool would just be
writing to some configuration file to /etc. But there is nothing stopping that
tool from instead using equivs to create local meta-packages of above
naming-style. Those packages would only be local and thus not bloat any
Packages file.
Of course this would require package maintainers to support the special
meta-package names generated by that tool but this cooperation is also required
should a special syntax be introduced. So instead of writing
Recommends: foo-print <!noprinting>
Package maintainers would write:
Recommends: foo-print | no-printing
I do not think that anything in policy is violated by having non-existing
packages in the Recommends, no? Policy §2.2.1 says about packages in main:
> must not require or recommend a package outside of main for compilation or
> execution (thus, the package must not declare a Pre-Depends, Depends,
> Recommends, Build-Depends, Build-Depends-Indep, or Build-Depends-Arch
> relationship on a non-main package unless that package is only listed as a
> non-default alternative for a package in main),
Strictly speaking, those meta-packages would not be in main but they would be
non-default alternatives and thus not violate this rule.
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature