Hi,

based on some discussion on IRC I want to propose install
profiles.

Recommends: foo <bar>
Suggests: foo <bar>

The syntax is the same as for build profiles, and it is
allowed in Recommends and Suggests fields only (maybe
Enhances?).

dpkg changes needed:

- Introduce /var/lib/dpkg/profiles with one profile per
line and commands to manage the list

dpkg --add-profile <profile>
dpkg --remove-profile <profile>
dpkg --print-profiles

- Introduce apt commands:

apt add-profile
apt remove-profile

These call the dpkg command and then install newly
activated Recommends or remove Recommends no longer
active.

Alternatively, dpkg doesn't need to care about which
profiles are active and apt manages the list.

Or one could invert the list and say we add profiles
we do not want. This might come in handy with profile
inheritance, where e.g. foo profile might imply bar
by default, but then you can request "foo !bar" for
your system.

Gentoo use flags have a default state, it seems
reasonable to follow the same approach, so you would
have

enable-profile
disable-profile
reset-profile

or something and the repository could declare default
profiles.

This allows users to customize their systems and avoid
installing recommends they don't want.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEET7WIqEwt3nmnTHeHb6RY3R2wP3EFAmSJ5CgACgkQb6RY3R2w P3FBoRAAlFbDxhXvbvveO2FjzO2Tnq64YUyPe8KBDyfMikXNmCgyJ/mtLnt3M+2t 5BvAyD+FxshIXjHEYbBjBFY9W/0gAksn5Gbfr8sZ4y2qUAzlNqCCRsPZSrNWtxSG HB3nsYbI4uSZpH/zu3rX5Mb3FYbZUZtZXoA3LqC3zLdwqF9EhfcOQA62YDRWmPpq ODzI2bOV7zI0zvJsNlacAVcXqPMBYN4uzL6ne0+jcB5xucCq2gj4oyYp7/EkW6Lu S6ciyKKELv29vr/f0otfOaAeoAd8QobcQKRfDhXd7t9+IODY9XT8i3JCOudUW4cS 71D9BOMfJBm8bpZTPTyroIadlVGN4pEWoUVaNiiRJ5KJA7A6ipUo5DkgjnvVacbU XhdrhxA1KFxAKLulWICFKH08PRPSyWfMUhA++LXotuNdtUxepxMXjhDbk+MRu5/N Q80LzyQ6URRJHkQGY6clSfAj3ejhiIjQUYG6H+m4IYgtcgVV15c09u5k67PgfZMT Ba17u23zJCtFqXhB9aJJaDXa1wHXGWdrWEljlYidc4e+CKGVKt8sssfNeth0w22b IL5QsRhtKquKXEvKotKdIJ7JZHGZ2nP+PiBS2Hqgs/SXRN2hozvt0zHil9KCg4+/ CwpSuRT+LSPQx4WZDww6x6A05B4/h0zkoN9RE15HFhSJK5bI/B8=
=3KrP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Ori

On Wed, Jun 14, 2023 at 06:00:42PM +0200, Julian Andres Klode wrote:

Hi,

based on some discussion on IRC I want to propose install
profiles.

Recommends: foo <bar>
Suggests: foo <bar>

The syntax is the same as for build profiles, and it is
allowed in Recommends and Suggests fields only (maybe
Enhances?).

Alternative backwards compatible approach:

Packages declare Profiles: they are part of

and then either

* apt ignores Recommends for disabled profiles
* apt installs Suggests for enabled profiles

It's not clear to me basically what's more powerful,
declaring profiles on relationships, or the packages.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEET7WIqEwt3nmnTHeHb6RY3R2wP3EFAmSJ6PQACgkQb6RY3R2w P3H3gQ//awoiXB5wiHr877nZhMEbfvV+8YZT74IBF3mF2Ghx86hqJHeN+ztm+4Ld 3gk9G7q9no+YnytyOTWBm0XBI0APuN6NZnCuDmbmSJ68G+TPPZSN0wlA6qaRxDXG tRZ2Ijea/LXUQRhfouBnrm6IwVlWfKNg6Rme5LFrFS9kK8jmCGMSdWWaM0BGqD8h Dig1uLL9wcAVH1gU6PtNZiIhr2SIwIGTjNAHJyjxpWMRi+OYMi1xYLqNVF1omekM 65l3BvZWdAaUZGa32Lpmb+FATpZzJkk1/lO1iz5MeEwbhyx7+PT6ZlBELeojypUN 4JuYaqDxKqMyj/RtaPgRmUltFTNez72kGVQ50Cj4bX6SZ8GCKJYUsgUFhxyZtcnE XyYv49KZ+QFkAEcC7jVNkD785lRfa1eTmdQ1u7rlZSzsfnJrpzaKayoyZBtIreX1 uoc/jdVd4/4WQpRnDlDC+sb3AMVPbXVUgUY/gEF4uZFz/lzgzWbIhQb12Z4GgaoW rOv3WYFjDSIpjmS4Rm1VkGQGPA2d4ocQHqQoLYZM8vzc8juYZlJjQMMpivdONnBJ NEJqnZtUpoG6PQRetE8V8FT1Iez/UdpMrOjM3oslQtOxRv6xv++XVfzkAG4SybXK kZv4v+aI0RdSCsQ0+W1lXadyAbbJA1iJ2UwBUr1U4vPk1f1G4a4=
=+CBf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Ori

Hi,

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 of software in our archive that tries to parse the package relationship fields. Anybody who wants to change the syntax of these fields has to be prepared to send patches to all of these software packages. This was not fun when I did the implementation for build profiles. And there is more software handling binary packages than software handling source packages.

So there is a huge cost to implement this properly in all the tools that need to be able to understand this. What is the benefit?

When I implemented the build profile syntax, profiles were the only way forward to make packages cross-buildable without hacks. So having them was a necessity and it made the huge workload reasonable.

What is the benefit of your proposal? That now your system may require a few hundred MB less disk space because you maybe have less packages installed? Is this worth the hassle? Will somebody who worries about disk space that much not rather turn off installing recommends by default?

And how many packages will make use of this? Once we have an idea of that, what will be the space savings on user's systems?

Are you prepared to do the work? It will be a lot.

Thanks!

cheers, josch
--==============‰63030760282517973=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmSJ+REACgkQ8sulx4+9 g+Ek+A//aaxOoJ1C/IAB++DiKOoWnfMyQwNkh+SXDw+F4Ce2/O9UrpGq5LSLR/xp k6P+uNqbncYYoGBJmtlZAlzvM4IQr9HHKMxxWyru/o8+7zjgnmQTUrclbKJKeY7J TnfahVgZu2S3IVzzEcserhrfZg5ZGjhpjlEFEdSNeRWHHKB5zA9Lqvw4mtyH75fE UkEODeJqCCjA6m8bdVfMApQ45VGMdkHVD6SKNk10Lf/41M0YcOKwm1kOdXKX/RMc /s0YBCiBfRohWh/8nl3pvB8WXYwT40jxwtWhA4SvNMriffdZo/sDV8xuat3EugHN 0Qj0lnup1LTY6A6qKmtL6p1N0Vrx7ePHmKQdS8FMlHtjaIvccwefhxb6fgEBcWRV ZGnaeqawSxv6HvGOqfM/T6nKxKIAtY2RB4NV9qAfNxpjvfc3Z/hPVkZuQ2FDCjbM AnfufOm7geQSu7Y0ouXonsu5seI1pGMUpl+6mjU3hVB3UkGH3Wqb9rYslRl7ig9X GyJl6vfjx5KMuT6Z9IwQcIYfIPnAVMarsr2Z+137/UFwe4DzuSaWlnFBKIVRjgi3 hTBaXZy3RRwgT8cmR1hjwa3CgrBVJvsHKuj1MCpDT+7DQ6+gG6+PwjTd6ZKVfgap rzT8OraWGPKgAkVNRZM8rcR75n/U+6tURD5+ToTRWNvs5ljSw6U=
=zEh1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2023-06-14 at 18:00:42 +0200, Julian Andres Klode wrote:

based on some discussion on IRC I want to propose install
profiles.

Recommends: foo <bar>
Suggests: foo <bar>

The syntax is the same as for build profiles, and it is
allowed in Recommends and Suggests fields only (maybe
Enhances?).

My first reaction to this was similar to the one from Josch. But the
more I think about it the more problems I see with it. Besides the implementation costs, I see these following problems or red flags:

- Making it apply only to the weak dependency fields makes this
inconsistent. But I understand applying it to the strong dependency
fields would be problematic as that could make dependency branches
suddenly disappear (which would be _bad_).
- The build-profiles syntax is already usable in these fields but
at build time, so this already means it's another backwards
incompatible change, or there would need to be a way to escape
these to pass them through (ugh).
- The build-profiles is local metadata that applies only to the
package currently being built. Instead applying this to installed
packages changes the semantics to be global, which means incremental
additions of such metadata might have surprising effects.

Alternatively, dpkg doesn't need to care about which
profiles are active and apt manages the list.

If support for this got added as proposed, and dpkg did not track
it, then other frontends or tools would need to also consult apt which
seems like a layer violation to me. Dependency wise dpkg would not
really care (except for reporting) as it does not enforce these weak
fields.

Gentoo use flags have a default state, it seems
reasonable to follow the same approach, so you would
have

enable-profile
disable-profile
reset-profile

or something and the repository could declare default
profiles.

I don't think this is comparable with Gentoo USE flags, as those, just
like build-profiles, are only applied at build-time (AFAIR).

This allows users to customize their systems and avoid
installing recommends they don't want.

This looks like a very narrow use for the amount of work and breakage
involved TBH. Are there really that many recommended or suggested
packages that can be described unambiguously with such profiles? One
thing is selecting features at build-time (say LDAP or choosing TLS implementation or whatever) the other is selecting features at the
package level, which seems would not mesh well, as you might have a
package providing say and LDAP plugin and something else. And then
also how that depended on package is being used.

In the end this looks a like a mismatch of concepts.

If this was at the package level, then we already have something that
kind of annotates multiple facets of a package (debtags), so perhaps
apt could use those instead. Either that or perhaps dpkg or frontends
could grow a way to let the users add annotations to packages as to
why they should not be installed f.ex.? I think there's a request
from Daniel Burrows about this.

If this is specific to the relationship from package A to B, then I
think I'm not seeing this as being very generic TBH, in addition to
all the problems listed above.

Regards,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmSMY6MACgkQMRvlz3HQ eIPTRw//dGAiHwLW0xriOpmzq4oz9qogR9cqSJip4HNzwSBNyeyyyFsYtjGzpigO GBj+XWg02CZoeVLMiCqe9EHW0ZGQCuIfiljzwKAfaIg/FgQsS1lJ7V7qxXmBJ18X bz6mBk0jHi4xaGQmf5a75TIypL68Q34Bq3HHwe9hAIGKZj7w6flu8GseBnIxDiOf QigeBn1Ock5JB/Mx9T9dnTZSaF+tJWRFi8RE2aDTlTZ0uvfn5RoWccAZF4g8iKRF OPOUDXEi7eK2uKJn2CJ/20zPTqtaGJbaoovOVlX0BH8/wMfg6hqWAj/XCLWUgj/I RRe4OK7o+5y5jy05rj0JBS9m+mQJAqO7T1ACGg8vm9Yzrdu/OxeORzFRjHjn9sUF lhHWBuCdVd8OlFFA9+xDOiDdqc5P80TZ9vW34l0YM+3WVa6lTaPIrnvJ/jYvjgu2 wZFfCsBgK3CaPgxdJj9B9NRa7Syrjxyuxzj/IFTq9QzzjEgC6cN5ImeY34eMyxNQ nm62Dv7r5Wdrh4Ezqt96cyGM3rwZAKzExlLZEIQfr/9cQoe2HD3bbUYWApgeZxuO SmQ87eUadRvtGtFnHJOHfyxzE/1kcbDkT0QnfCn/9mYo556yfUdpMcOdCv5FLuS7 97q3/HzWxZUqvpoxzmxVNxFZjvmiuyJUybUtcG4vA7Ga3086SR4=
=ylUz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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, josch
--=============='60495353241905571=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmSMeiMACgkQ8sulx4+9 g+FTrw//Wn3LpskSYY3LVYtSHbi8+8EF+OD0MBjhLEtguD/9K9X0J68fXFDmULJe ZioaljyT/NVsdoJ2Wa8+WYoV9EzVfGjLaTTjqZ08NLezzt3gVT5gbQXdUZ/rAzVW BEajRLUVarqNu8yiUVoVQ5ofakj3xWhoXvhtJ76fGl7eGIdLSL9i5DjqLmeTJd52 ouYiuLW2n5bDDV3mhYuk/tQVdQvAuPO0Z1hw61ekoCdOMKnwQZReCzvVYTph5lQh JZ13NLmHl/FmGwb0bok5M2DthI0qJaQ4Y/BmiYf5tHSRE85EgIN0SMl8dsu/07L3 I2Sj9svEaZbrp+ge7nzMkKq8I3gFTRcMhENdquF6NVXNdQwzGr9SWVHOlw1mr4bl lcKY8Ec1lLjTkTIwMg4R0allcnwer4I9ye3IShoBWFY6iELhVJfCUKJfTFi30GHo RlptiIXysGS7+OZo+myVSaBJQ+Ws2MxevQy5kGKpkUH8V+ZpAZ1WWfr8noS9A1qt 6IsKVScSI22Zg/gk4YDebxPn7Un0yQjWc4iK5qoaunNoqwngz535C9DPzEDTsKNX XdlcxbznZ36x3wtd8AqhIbqg5tmiLJpdLWuDZYgGxjzSyK55pQ9xaoqI5nvYdKby njPFd7HEqIsfCRTA5ugVSEMPCAUFCXTtpdQstK5N8/ZA9juiH2Q=
=LJP8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le vendredi 16 juin 2023, 15:29:14 CEST David Kalnischkies a écrit :

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 also install foo (e.g. install firefox-l10n-de if firefox
is installed and user wants german language packs)

A similar example for the skanpage scanning software from KDE : it requires tesseract-ocr-$language to make OCR working for $language.

Currently the only options I can think of are installing all tesserract-ocr-* languages when the user installs skanpage, install tesseract-ocr-$lang alongside task-$lang-desktop, or don’t have OCR available by default (current state) all of which have
various issues.

This came up as #1030620 recently.


I’m pretty sure there were more such issues raised in the past for desktop software where optional deps would improve the behaviour for our users, but cannot remember off the top of my head.


Cheers,
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)