[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building GTK programs without installing dconf-service?



On Fri, 16 Aug 2019 at 00:13:28 +0200, Jonas Smedegaard wrote:
> Are you arguing that an installation where in-memory storage of config 
> is fine is perhaps not an "unusual installation" but a "veeeeery super 
> dooper weird installations" and therefore does not match Debian Policy 
> about using Recommends?

Let's not polarize this into "either A or B is important and the other is
irrelevant". I am arguing that this is a situation where two competing
factors have to be balanced, and not a situation where one of those
factors is obviously much more important than the other:

* non-essential dependencies should be weakened to Recommends or Suggests
  to make the overall system more flexible;
* users who change configuration should be able to rely on it not being
  lost

You have made a good point in favour of the first of those being
desirable, and I don't disagree; but however many times you say that,
it doesn't demonstrate consensus that the first of those factors is more
important than the second. (You are arguing that it is; Adam seems to
be suggesting that it isn't.)

If there *is* consensus that "don't lose user configuration" is less
important than "weaken dependencies where possible", then that's a good
reason to weaken the dependency, although in practice that is likely to
be wontfix until dh_installgsettings can do it. As far as I can tell,
this feature has not been supported or proposed in the 8 years since
dh_installgsettings was added to debhelper, but I have now opened a
debhelper bug with a possible patch.

Policy is a tool to make the best software distribution we can by
documenting consensus, not an immutable holy book. If following the
letter of Policy implies making a change that (according to project
consensus) gives us a worse software distribution, then we should change
Policy instead.

I help to update GTK in the GNOME team, but I don't consider GTK to be
"my" package, and I am not going to overrule its primary maintainers on
decisions that I am not confident have consensus behind them.

    smcv


Reply to: