Re: Install profiles
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
Reply to: