Building GTK programs without installing systemd-sysv?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Jonas Smedegaard-2
Quoting Simon McVittie (2019-08-16 11:00:37)

> 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.
Great points!

Thanks for your patience and clarity!!


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

Ian Jackson-2
In reply to this post by Adam Borowski-3
Adam Borowski writes ("Re: Building GTK programs without installing systemd-sysv?"):

> On Wed, Aug 14, 2019 at 01:47:47PM +0200, Philipp Kern wrote:
> > You want dbus-x11 instead of dbus-user-session then, I think.
>
> For this and related issues, I wonder if it would be better to replace the
> virtual package pair of {default-,}dbus-session-bus with a real dummy
> package that has:
> Depends: dbus-x11 | systemd-sysv, dbus-user-session | dbus-x11
>
> This would pull in dbus-user-session for systemd users, dbus-x11 for any
> other init.
>
> (The idea might be bogus -- I haven't slept since Monday morning; anyone up
> for beersigning near Frankfurt airport until late evening?)

I didn't see any response to this and I don't immediately see why it
would be a bad idea.

Obviously it's slightly a bodge but these kind of issues involving
dbus-user-session seem common enough that it would probably be worth
doing this as a workaround, if it would be effective.  (Which it seems
like it probably would be.)

Adam, have you tested this (on both systemd and sysvinit systems) ?

Thanks,
Ian.

(at the Worldcon in Dublin so not got the bandwidth to check this
myself.)

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

Adam Borowski-3
On Sat, Aug 17, 2019 at 01:53:32PM +0100, Ian Jackson wrote:

> Adam Borowski writes ("Re: Building GTK programs without installing systemd-sysv?"):
> > On Wed, Aug 14, 2019 at 01:47:47PM +0200, Philipp Kern wrote:
> > > You want dbus-x11 instead of dbus-user-session then, I think.
> >
> > For this and related issues, I wonder if it would be better to replace the
> > virtual package pair of {default-,}dbus-session-bus with a real dummy
> > package that has:
> > Depends: dbus-x11 | systemd-sysv, dbus-user-session | dbus-x11
> >
> > This would pull in dbus-user-session for systemd users, dbus-x11 for any
> > other init.
> >
> > (The idea might be bogus -- I haven't slept since Monday morning; anyone up
> > for beersigning near Frankfurt airport until late evening?)

> Obviously it's slightly a bodge but these kind of issues involving
> dbus-user-session seem common enough that it would probably be worth
> doing this as a workaround, if it would be effective.  (Which it seems
> like it probably would be.)
>
> Adam, have you tested this (on both systemd and sysvinit systems) ?

Alas, not yet -- I've barely returned from Brazil, and my TODO list is
bursting at seams.  Might be good to get feedback first, as talk is cheap.

There are also two separate issues:
* apt failing to find a solution, despite it existing
* functionality of both dbus implementations

For now, we can fix the first part quite easily.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Simon Richter
In reply to this post by Simon McVittie-7
Hi,

On Fri, Aug 16, 2019 at 10:00:37AM +0100, Simon McVittie wrote:

> * 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

After thinking about it over the weekend and deleting a much longer draft,
I think the relationship should be demoted to Recommends, and the stack
fixed to report the error instead of silently losing data if the service is
unavailable.

The rationale for the demotion is simple: this is a component dependency,
not a library dependency.

Component dependencies:

 - refer to interfaces, not implementations (i.e. any component that
   provides X)
 - may be circular without any component being aware of that
 - may resolve to a list of components (e.g. plugins)

Because of circularity, hard "Depends:" is out. Applied to the case at
hand, it would be absolutely valid to have a GUI application based on Gtk
that provides a gconf-settings interface (for example, as part of a session
manager), and such a program would generate a Depends cycle.

The other two things are not represented well in our package system, and
I'm not entirely sure that it would be possible to do that properly,
because components are resolved at runtime through several different
activation methods, and most of them cannot be statically analyzed.

Windows circumvents the problem by pulling most core components into the
base system, and generating application manifests during linking that are
included as a comment section in the executable, listing component
dependencies for static analysis and allowing diagnostics at program start
if components are missing rather than unexpected behaviour later.

I'd be entirely fine with a program displaying an error dialog at startup
if a missing service is unavailable.

What I'm not fine with is silently instantiating a dummy component that
implements the interface but not the functionality, that's just a bug.

Papering over the problem by creating a hard dependency in the package
system so the buggy code is never reached is not a solution.

   Simon

12