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
|

Building GTK programs without installing systemd-sysv?

Simon Richter
Hi,

I have a few users who do test builds of kicad on my server, so I'd like to
provide the necessary build dependencies, but since a few days, the
dependency chain

    libwxgtk3.0-gtk3-dev
      libwxgtk3.0-gtk3-0v5
        libgtk-3-0
          libgtk-3-common
            dconf-gsettings-backend
              dconf-service
                dbus-user-session
                  libpam-systemd
                    systemd-sysv

stops gtk upgrades from happening because I have pinned systemd-sysv to
-100 to avoid repeating the last unfortunate incident where I had to drive
to the colo facility.

Does anyone with more insight into which of these dependencies are actually
hard requirements have a suggestion if we could demote one of them to a
Recommends?

And in the long run: would it make sense to require that packages that are
build dependencies of something can be installed without starting any
service?

   Simon

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

Holger Levsen-2
On Wed, Aug 14, 2019 at 12:40:24PM +0200, Simon Richter wrote:
> And in the long run: would it make sense to require that packages that are
> build dependencies of something can be installed without starting any
> service?

why not build in your favorite container?


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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

Re: Building GTK programs without installing systemd-sysv?

Philipp Kern-6
In reply to this post by Simon Richter
On 8/14/2019 12:40 PM, Simon Richter wrote:

> I have a few users who do test builds of kicad on my server, so I'd like to
> provide the necessary build dependencies, but since a few days, the
> dependency chain
>
>     libwxgtk3.0-gtk3-dev
>       libwxgtk3.0-gtk3-0v5
>         libgtk-3-0
>           libgtk-3-common
>             dconf-gsettings-backend
>               dconf-service
>                 dbus-user-session
>                   libpam-systemd
>                     systemd-sysv
>
> stops gtk upgrades from happening because I have pinned systemd-sysv to
> -100 to avoid repeating the last unfortunate incident where I had to drive
> to the colo facility.

You want dbus-x11 instead of dbus-user-session then, I think.

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

Simon Richter
Hi,

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.

Ah, that works, and aptitude is able to resolve that automatically (but apt
gets confused). So the immediate solution works for me and I'll file a bug
against apt. Thanks a lot!

The long term question remains though -- I dimly remember that we once had
the same discussion about a library pulling in rpcbind, and that made a lot
of people very unhappy at the time.

   Simon

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

Adam Borowski-3
In reply to this post by Philipp Kern-6
On Wed, Aug 14, 2019 at 01:47:47PM +0200, Philipp Kern wrote:

> On 8/14/2019 12:40 PM, Simon Richter wrote:
> > I have a few users who do test builds of kicad on my server, so I'd like to
> > provide the necessary build dependencies, but since a few days, the
> > dependency chain
> >
> >     libwxgtk3.0-gtk3-dev
> >       libwxgtk3.0-gtk3-0v5
> >         libgtk-3-0
> >           libgtk-3-common
> >             dconf-gsettings-backend
> >               dconf-service
> >                 dbus-user-session
> >                   libpam-systemd
> >                     systemd-sysv
> >
> > stops gtk upgrades from happening because I have pinned systemd-sysv to
> > -100 to avoid repeating the last unfortunate incident where I had to drive
> > to the colo facility.
>
> 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?)


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 systemd-sysv?

Andrey Rahmatullin-3
In reply to this post by Simon Richter
On Wed, Aug 14, 2019 at 02:24:26PM +0200, Simon Richter wrote:
> The long term question remains though -- I dimly remember that we once had
> the same discussion about a library pulling in rpcbind, and that made a lot
> of people very unhappy at the time.
There was also http://bugs.debian.org/658541 for libimobiledevice and
usbmuxd (it is now Recommends).

--
WBR, wRAR

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

Re: Building GTK programs without installing systemd-sysv?

Philipp Kern-6
In reply to this post by Simon Richter
On 8/14/2019 2:24 PM, Simon Richter wrote:
> The long term question remains though -- I dimly remember that we once had
> the same discussion about a library pulling in rpcbind, and that made a lot
> of people very unhappy at the time.

As Holger said: Then use a chroot. With policy-rc.d you can deny service
startup, which is also what the builders do.

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Simon McVittie-7
In reply to this post by Simon Richter
On Wed, 14 Aug 2019 at 14:24:26 +0200, Simon Richter wrote:
> The long term question remains though -- I dimly remember that we once had
> the same discussion about a library pulling in rpcbind, and that made a lot
> of people very unhappy at the time.

I think this is a bit of a lose/lose situation: if we downgrade the
Depends to Recommends, as long as there is an (IMO unwise) meme that
globally disabling Recommends is the right thing to do for "efficient"
and "minimal" systems, people will install GTK programs on their desktops
with Recommends disabled, and be surprised (and/or open high-severity
bugs) when settings aren't saved as a result.

     libwxgtk3.0-gtk3-dev
       libwxgtk3.0-gtk3-0v5
         libgtk-3-0

None of the dependencies above here can be broken because of how shared
libraries work.

           libgtk-3-common

This is an implementation detail of libgtk-3-0, containing its /usr/share.
GTK won't work without at least the GSettings schemas (the GSettings
API is such that installing the code without the settings schemas is
considered to be invalid / a packaging error), so Depends is right.

             dconf-gsettings-backend | gsettings-backend

This dependency is generated by dh_installgsettings as a result of
libgtk-3-common containing GSettings schemas. It *could* be downgraded
to a Recommends, but then the user of GSettings (in this case GTK)
would fall back to the in-memory settings backend, which doesn't
actually persist any settings. Not so good. These days there's also a
GKeyFile-based backend, which is used inside Flatpak containers; but I
think that has problems with multiple writers overwriting each other's
changes (like they would tend to for anything else based on a simple
text configuration file written by more than one user of a library),
which makes it undesirable outside constrained single-app situations
like Flatpak. There's also no migration path between that and dconf, so
installing dconf-gsettings-backend would result in your previous settings
apparently disappearing, which would probably also be considered to be
a high-severity bug.

               dconf-service

dconf-gsettings-backend cannot save any settings without the service that
deals with change-notification and arbitration between multiple writes
(that's how dconf works), so this should probably be a hard dependency.

                 dbus-user-session | dbus-x11 (effectively)

dconf is a D-Bus session service which won't work, at all, without a
D-Bus session bus. In a more opinionated distro, maybe we would leave out
this dependency and just assume that working D-Bus is part of a standard
GUI installation (the same way we have that assumption for working X11),
but my understanding is that in Debian that would be considered to be a
bug (and in a more opinionated distro, we'd probably also have gone for
systemd 100%, rather than remaining in a superposition of states). So
this needs to be a hard dependency.

dbus-user-session is the preferred option on any machine that boots with
systemd, because it uses a real service manager, gives the session bus
a well-defined lifetime, and works for Wayland, X11 and non-graphical
sessions; whereas dbus-x11 (dbus-launch) only works for X11 sessions,
results in the dbus-daemon being a child of an arbitrary process with
an unpredictable execution environment, and is constrained by the need
to avoid breaking assumptions that are not necessarily valid or relevant
this decade.

                   libpam-systemd
                     systemd-sysv

dbus-user-session relies on `systemd --user`, which needs systemd-logind
*and* systemd as pid 1 (a systemd-logind clone like elogind is not
enough), so this really is a hard dependency.

If someone implements a sufficiently capable non-systemd user-service
manager to provide the dbus-user-session semantics without systemd[1],
I'd be willing to consider hooking up dbus-user-session to that as
an alternative dependency.

     smcv

[1] briefly: one dbus-daemon per "user-session", already listening before
    ordinary user processes can run, where a user-session is a contiguous
    overlapping set of login sessions under the same uid (this is the
    same as the lifetime of XDG_RUNTIME_DIR in the freedesktop.org
    basedirs specification); and then use the dbus-daemon's socket
    address "$XDG_RUNTIME_DIR/bus" to set $DBUS_SESSION_BUS_ADDRESS for
    all ordinary user processes

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Jonas Smedegaard-2
Quoting Simon McVittie (2019-08-14 17:59:00)

> On Wed, 14 Aug 2019 at 14:24:26 +0200, Simon Richter wrote:
> > The long term question remains though -- I dimly remember that we
> > once had the same discussion about a library pulling in rpcbind, and
> > that made a lot of people very unhappy at the time.
>
> I think this is a bit of a lose/lose situation: if we downgrade the
> Depends to Recommends, as long as there is an (IMO unwise) meme that
> globally disabling Recommends is the right thing to do for "efficient"
> and "minimal" systems, people will install GTK programs on their
> desktops with Recommends disabled, and be surprised (and/or open
> high-severity bugs) when settings aren't saved as a result.
Please follow Debian Policy, and let those misguided souls have their
surprises.


 - 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 dconf-service?

Simon McVittie-7
On Wed, 14 Aug 2019 at 19:52:42 +0200, Jonas Smedegaard wrote:

> Quoting Simon McVittie (2019-08-14 17:59:00)
> > I think this is a bit of a lose/lose situation: if we downgrade the
> > Depends to Recommends, as long as there is an (IMO unwise) meme that
> > globally disabling Recommends is the right thing to do for "efficient"
> > and "minimal" systems, people will install GTK programs on their
> > desktops with Recommends disabled, and be surprised (and/or open
> > high-severity bugs) when settings aren't saved as a result.
>
> Please follow Debian Policy, and let those misguided souls have their
> surprises.

Which point in the dependency chain do you think should be weakened from
Depends to Recommends? I think the dependency from libgtk-3-0-common
generated by dh_installgsettings is probably the most appropriate, or at
least, least inappropriate? (This would require debhelper changes to add
a dh_installgsettings option analogous to dh_shlibdeps -- -dRecommends,
so that the dependency could be moved to ${misc:Recommends}.)

When an angry user turns up on the BTS complaining that GTK has a
grave bug (configuration lost) or a serious bug (Policy §3.5, missing
dependencies), is there consensus that this should be considered to
be not-a-bug and closed?

I thought I remembered Policy having something to say about weakening
shared libraries' dependencies on services to Recommends or weaker
(e.g. libdbus-1-3 only Recommends dbus and does not depend on it, even
though it's of little use without dbus), but now I can't find it in
Policy, and I also can't find a bug asking for that. Does this exist,
or did I imagine it?

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Adam Borowski-3
On Wed, Aug 14, 2019 at 07:22:33PM +0100, Simon McVittie wrote:
> Which point in the dependency chain do you think should be weakened from
> Depends to Recommends? I think the dependency from libgtk-3-0-common
> generated by dh_installgsettings is probably the most appropriate, or at
> least, least inappropriate?

I believe that full Depends is ok.  The original reporter's problem wasn't
about bloat, but about libgtk-3's dependency chain pulling in system-sysv in
a way that makes apt refuse to install it otherwise without some obscure
knowledge on the part of the user, that eludes even some DDs.

> When an angry user turns up on the BTS complaining that GTK has a
> grave bug (configuration lost) or a serious bug (Policy §3.5, missing
> dependencies), is there consensus that this should be considered to
> be not-a-bug and closed?

Aye, good point.

> I thought I remembered Policy having something to say about weakening
> shared libraries' dependencies on services to Recommends or weaker
> (e.g. libdbus-1-3 only Recommends dbus and does not depend on it, even
> though it's of little use without dbus), but now I can't find it in
> Policy, and I also can't find a bug asking for that. Does this exist,
> or did I imagine it?

That proposal was about moving Depends:/Recommends: relationships, not about
removing them.  Since, as you describe, the programs would still require
*conf to save their data, it wouldn't fix this particular problem.


One idea I have would be to change the way dbus-session is chosen, with
a real metapackage that defaults to dbus-user-session if systemd is already
installed or dbus-x11 if not, but that's just brainstorming, and my brain
hasn't slept in 60 hours.


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?

Jonas Smedegaard-2
In reply to this post by Simon McVittie-7
Quoting Simon McVittie (2019-08-14 20:22:33)

> On Wed, 14 Aug 2019 at 19:52:42 +0200, Jonas Smedegaard wrote:
> > Quoting Simon McVittie (2019-08-14 17:59:00)
> > > I think this is a bit of a lose/lose situation: if we downgrade
> > > the Depends to Recommends, as long as there is an (IMO unwise)
> > > meme that globally disabling Recommends is the right thing to do
> > > for "efficient" and "minimal" systems, people will install GTK
> > > programs on their desktops with Recommends disabled, and be
> > > surprised (and/or open high-severity bugs) when settings aren't
> > > saved as a result.
> >
> > Please follow Debian Policy, and let those misguided souls have
> > their surprises.
>
> Which point in the dependency chain do you think should be weakened
> from Depends to Recommends? I think the dependency from
> libgtk-3-0-common generated by dh_installgsettings is probably the
> most appropriate, or at least, least inappropriate? (This would
> require debhelper changes to add a dh_installgsettings option
> analogous to dh_shlibdeps -- -dRecommends, so that the dependency
> could be moved to ${misc:Recommends}.)
libgtk-3-0-common could even be relaxed to _suggest_ dconf/gconf since
already the applications using dconf/gconf declare a dependency on those
disk-based backends.


> When an angry user turns up on the BTS complaining that GTK has a
> grave bug (configuration lost) or a serious bug (Policy §3.5, missing
> dependencies), is there consensus that this should be considered to be
> not-a-bug and closed?

Issues solely caused by disregarding recommends should be closed as
not-a-bug indeed.  Why do you ask?  If you somehow disagree with that,
then I can only take it that you disagree with Debian Policy and it
makes sense to deal with that instead of cowardly putting it on me.


> I thought I remembered Policy having something to say about weakening
> shared libraries' dependencies on services to Recommends or weaker
> (e.g. libdbus-1-3 only Recommends dbus and does not depend on it, even
> though it's of little use without dbus), but now I can't find it in
> Policy, and I also can't find a bug asking for that. Does this exist,
> or did I imagine it?

Sorry, I am not Paul Wise or Colin Watson ;-)


 - 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 dconf-service?

Simon McVittie-7
On Wed, 14 Aug 2019 at 20:59:04 +0200, Jonas Smedegaard wrote:
> libgtk-3-0-common could even be relaxed to _suggest_ dconf/gconf since
> already the applications using dconf/gconf declare a dependency on those
> disk-based backends.

The dependency is not because applications store configuration via
GSettings, it is because GTK widgets themselves store configuration (which
is shared between all applications that use those widgets) via GSettings.
The most prominent of these widgets is probably the file chooser
(File -> Open or File -> Save As dialog). Whenever applications use those,
preferences like the sort order are stored via GSettings, even if the
application itself has no mention of GSettings in its source code and
no reason to add a dependency on a GSettings backend on its own behalf.

abiword and audacity are examples of applications that depend on GTK,
probably use file chooser dialogs, but do not depend on a GSettings
backend themselves because they do not use GSettings directly.

The preferences stored in this way are not vitally important, so perhaps
it would be OK for them to just not be propagated outside the application
or stored after it exits (with a warning on stderr) if the GSettings
backend is missing; but it isn't obvious to me that there would be
consensus about that not being a (RC?) bug, which is why I asked.

I suppose one way to represent that in the spirit of what you're saying
would be to drop libgtk-3-0-common's dependency on a GSettings backend,
and make GTK's shlibs/symbols generate a dependency like

    libgtk-3-0 (>= x.y), dconf-gsettings-backend | gsettings-backend

instead of just libgtk-3-0? But I don't think that works, because
it would only move the problem up one level, and instead of "I
installed libgtk-3-dev and it pulled in dconf-service", we'd have "I
installed libgtk-vnc-2.0-dev and it pulled in dconf-service" (where
libgtk-vnc-2.0-dev Depends: libgtk-vnc-2.0-0 which is an arbitrarily
chosen library that Depends: libgtk-3-0).

> Issues solely caused by disregarding recommends should be closed as
> not-a-bug indeed.

This is a good rule of thumb, but there must be some point on the scale
between "not required" and "is a hard dependency" where a Recommends
becomes a Depends. If libgtk-3-0 only had a Recommends on libatk1.0-0
(because libgtk-3-0 contains both GDK and GTK, and strictly speaking
you can use GDK without ATK, as long as you don't also link to GTK),
I think there would be consensus that it would be wrong to consider
"libgtk-3-0 should depend on libatk1.0-0" to be not-a-bug.

Obviously failure to store some preferences is less serious than "one
of the two libraries doesn't work at all", but neither is an absolute:
they're both points on a continuum.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Jonas Smedegaard-2
Quoting Simon McVittie (2019-08-14 22:20:05)

> On Wed, 14 Aug 2019 at 20:59:04 +0200, Jonas Smedegaard wrote:
> > libgtk-3-0-common could even be relaxed to _suggest_ dconf/gconf
> > since already the applications using dconf/gconf declare a
> > dependency on those disk-based backends.
>
> The dependency is not because applications store configuration via
> GSettings, it is because GTK widgets themselves store configuration
> (which is shared between all applications that use those widgets) via
> GSettings. The most prominent of these widgets is probably the file
> chooser (File -> Open or File -> Save As dialog). Whenever
> applications use those, preferences like the sort order are stored via
> GSettings, even if the application itself has no mention of GSettings
> in its source code and no reason to add a dependency on a GSettings
> backend on its own behalf.
>
> abiword and audacity are examples of applications that depend on GTK,
> probably use file chooser dialogs, but do not depend on a GSettings
> backend themselves because they do not use GSettings directly.
Ah, thanks for pointing that out.


> The preferences stored in this way are not vitally important, so
> perhaps it would be OK for them to just not be propagated outside the
> application or stored after it exits (with a warning on stderr) if the
> GSettings backend is missing; but it isn't obvious to me that there
> would be consensus about that not being a (RC?) bug, which is why I
> asked.

Would it be fair to describe both widget and application needs for
file-based config backend as required in "all but unusual
installations."




> I suppose one way to represent that in the spirit of what you're
> saying would be to drop libgtk-3-0-common's dependency on a GSettings
> backend, and make GTK's shlibs/symbols generate a dependency like
>
>     libgtk-3-0 (>= x.y), dconf-gsettings-backend | gsettings-backend
>
> instead of just libgtk-3-0? But I don't think that works, because it
> would only move the problem up one level, and instead of "I installed
> libgtk-3-dev and it pulled in dconf-service", we'd have "I installed
> libgtk-vnc-2.0-dev and it pulled in dconf-service" (where
> libgtk-vnc-2.0-dev Depends: libgtk-vnc-2.0-0 which is an arbitrarily
> chosen library that Depends: libgtk-3-0).
No, I don't mean that libgtk-3-0 should tell all its consumers that they
all should depend(!) on a file-based config backend.

I simply noticed that a bunch of applications currently declare a
dependency on those backends, without knowing how they grew that package
relationship.

Based on your enlightening me above, I'd say that libgtk-3-0 should
recommend those backends, and consumers of the config API provided by
libgtk-3-0 should also (ideally only by default, possible to
relax/tighten by each concrete package) recommend those backends as
well.


> > Issues solely caused by disregarding recommends should be closed as
> > not-a-bug indeed.
>
> This is a good rule of thumb, but there must be some point on the
> scale between "not required" and "is a hard dependency" where a
> Recommends becomes a Depends. If libgtk-3-0 only had a Recommends on
> libatk1.0-0 (because libgtk-3-0 contains both GDK and GTK, and
> strictly speaking you can use GDK without ATK, as long as you don't
> also link to GTK), I think there would be consensus that it would be
> wrong to consider "libgtk-3-0 should depend on libatk1.0-0" to be
> not-a-bug.
Not sure I follow you above.

If an application links with libgtk-3-0,

If libgtk-3-0 provides an API that links with both GDK and ATK and
gracefully handles consumers calling the ATK-related parts while libatk
is missing, then libgtk-3-0 should only recommend libatk.

If however using the parts of libgtk-3-0 API related to ATK causes the
library to segfault if libatk is missing, then libgtk-3-0 should depend
on libatk.

Or are you talking about some other kind of behaviour?


> Obviously failure to store some preferences is less serious than "one
> of the two libraries doesn't work at all", but neither is an absolute:
> they're both points on a continuum.

Question is not if a feature totally stops working when related package
is missing but instead if said feature truly is optional by _any_ extend
- i.e. is there some exotic situation where it is sensible to omit
without causing the code to become unstable?


 - 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 dconf-service?

Simon McVittie-7
On Wed, 14 Aug 2019 at 22:53:33 +0200, Jonas Smedegaard wrote:

> Quoting Simon McVittie (2019-08-14 22:20:05)
> > The preferences stored in this way are not vitally important, so
> > perhaps it would be OK for them to just not be propagated outside the
> > application or stored after it exits (with a warning on stderr) if the
> > GSettings backend is missing; but it isn't obvious to me that there
> > would be consensus about that not being a (RC?) bug, which is why I
> > asked.
>
> Would it be fair to describe both widget and application needs for
> file-based config backend as required in "all but unusual
> installations."

At least that strong, perhaps stronger. The definition of Depends in
Policy says "required for the depending package to provide a significant
amount of functionality", so GTK's settings probably don't qualify for
that, but application configuration maybe does.

I'm a little surprised that Policy §7.2 doesn't have anything to say
about packages having enough Depends to make the package work correctly,
work as designed or work without data loss, but perhaps that's considered
to be unnecessary, on the principle that Policy doesn't have to enumerate
every possible wrong thing.

> Based on your enlightening me above, I'd say that libgtk-3-0 should
> recommend those backends, and consumers of the config API provided by
> libgtk-3-0 should also (ideally only by default, possible to
> relax/tighten by each concrete package) recommend those backends as
> well.

This is not currently implementable without bypassing dh_installgsettings,
which doesn't currently have any way to add a weaker dependency than
Depends. I'll open a feature request at some point.

The conservative default would be Depends to avoid data loss
(configuration not being stored), but in any case debhelper can't
change its default for this without a compat bump: that would be an
incompatible change, and in particular packages don't normally use the
${misc:Recommends} substvar, so moving from Depends to Recommends without
per-package changes would in practice result in no relationship at all,
which is definitely too weak.

> > If libgtk-3-0 only had a Recommends on
> > libatk1.0-0 (because libgtk-3-0 contains both GDK and GTK, and
> > strictly speaking you can use GDK without ATK, as long as you don't
> > also link to GTK), I think there would be consensus that it would be
> > wrong to consider "libgtk-3-0 should depend on libatk1.0-0" to be
> > not-a-bug.
>
> Not sure I follow you above.

Sorry, this makes a rather less obvious example if you aren't familiar
with the libraries in question...

libgtk-3-0 contains libgdk-3.so.0 (GDK), a lower-level library,
and libgtk-3.so.0 (GTK), a higher-level library that depends on GDK.
Basically all users of these libraries depend on both, either because
they use both or because they only use the higher-level GTK, which depends
on the lower-level GDK itself; that's why the two libraries are combined
into a single binary package.

libgtk-3.so.0 (GTK) has an ELF DT_NEEDED relationship with
libatk-1.0.so.0, but libgdk-3.so.0 (GDK) doesn't.

If a program is linked to libgdk-3.so.0 (GDK) only, it can work without
libatk-1.0.so.0 being installed, so the libgtk-3-0 package does have some
(very niche) functionality without libatk-1.0.so.0. (I am not aware of
any specific programs that genuinely do this.)

If a program is linked to libgtk-3.so.0 (GTK), it cannot work at all
without libatk-1.0.so.0 being installed: ld.so exits with an error before
any user code has the opportunity to run.

I don't think it would be appropriate to weaken libgtk-3-0's
${shlibs:Depends} on the package that contains libatk-1.0.so.0 to a
Recommends, and then respond to the resulting grave bug report by saying
"well, *technically*, you *might* only be using GDK, so a Depends is too
strong", because in practice it's vanishingly rare to depend on GDK but
not GTK, and the failure mode when you depend on GTK but don't have its
library dependencies is that the program doesn't work at all.

(This is not about crashing or segfaulting, and is not about whether you
call particular functions; it's about whether the program can even reach
the beginning of main().)

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing systemd-sysv?

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

I ran into the same problem… in a chroot. Due to some bug,
systemd-sysv just did not want to install under cowbuilder
for some time.

I discovered that using the second alternative for *conf
worked: put this into /etc/apt/preferences:

Package: dconf-gsettings-backend
Pin: version *
Pin-Priority: -1

This will cause gconf-gsettings-backend to be used during
the build instead, which does not depend on systemd-sysv.

gl hf,
//mirabilos
--
This space for rent.

https://paypal.me/mirabilos to support my work.

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Jonas Smedegaard-2
In reply to this post by Simon McVittie-7
Quoting Simon McVittie (2019-08-15 20:55:04)

> On Wed, 14 Aug 2019 at 22:53:33 +0200, Jonas Smedegaard wrote:
> > Quoting Simon McVittie (2019-08-14 22:20:05)
> > > The preferences stored in this way are not vitally important, so
> > > perhaps it would be OK for them to just not be propagated outside the
> > > application or stored after it exits (with a warning on stderr) if the
> > > GSettings backend is missing; but it isn't obvious to me that there
> > > would be consensus about that not being a (RC?) bug, which is why I
> > > asked.
> >
> > Would it be fair to describe both widget and application needs for
> > file-based config backend as required in "all but unusual
> > installations."
>
> At least that strong, perhaps stronger.
Stronger than unusual how?

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?

Really?


[...]

> > > If libgtk-3-0 only had a Recommends on libatk1.0-0 (because
> > > libgtk-3-0 contains both GDK and GTK, and strictly speaking you
> > > can use GDK without ATK, as long as you don't also link to GTK), I
> > > think there would be consensus that it would be wrong to consider
> > > "libgtk-3-0 should depend on libatk1.0-0" to be not-a-bug.
> >
> > Not sure I follow you above.
>
> Sorry, this makes a rather less obvious example if you aren't familiar
> with the libraries in question...
>
> libgtk-3-0 contains libgdk-3.so.0 (GDK), a lower-level library, and
> libgtk-3.so.0 (GTK), a higher-level library that depends on GDK.
> Basically all users of these libraries depend on both, either because
> they use both or because they only use the higher-level GTK, which
> depends on the lower-level GDK itself; that's why the two libraries
> are combined into a single binary package.
>
> libgtk-3.so.0 (GTK) has an ELF DT_NEEDED relationship with
> libatk-1.0.so.0, but libgdk-3.so.0 (GDK) doesn't.
>
> If a program is linked to libgdk-3.so.0 (GDK) only, it can work
> without libatk-1.0.so.0 being installed, so the libgtk-3-0 package
> does have some (very niche) functionality without libatk-1.0.so.0. (I
> am not aware of any specific programs that genuinely do this.)
>
> If a program is linked to libgtk-3.so.0 (GTK), it cannot work at all
> without libatk-1.0.so.0 being installed: ld.so exits with an error
> before any user code has the opportunity to run.
>
> I don't think it would be appropriate to weaken libgtk-3-0's
> ${shlibs:Depends} on the package that contains libatk-1.0.so.0 to a
> Recommends, and then respond to the resulting grave bug report by
> saying "well, *technically*, you *might* only be using GDK, so a
> Depends is too strong", because in practice it's vanishingly rare to
> depend on GDK but not GTK, and the failure mode when you depend on GTK
> but don't have its library dependencies is that the program doesn't
> work at all.
>
> (This is not about crashing or segfaulting, and is not about whether
> you call particular functions; it's about whether the program can even
> reach the beginning of main().)
If applications cannot even start without libatk then obviously that's a
dependency (not a recommendation).

Your providing 2 libraries somewhat in concert one with different
requirements than the other seems to me a good case for using a
debian/*.symbols file: Only packages actually linking with GTK gets the
ATK dependency and packages only needing GDK API don't.


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

Simon McVittie-7
In reply to this post by Thorsten Glaser-7
On Thu, 15 Aug 2019 at 20:51:36 +0000, Thorsten Glaser wrote:
> I discovered that using the second alternative for *conf
> worked: put this into /etc/apt/preferences:
>
> Package: dconf-gsettings-backend
> Pin: version *
> Pin-Priority: -1
>
> This will cause gconf-gsettings-backend to be used during
> the build instead, which does not depend on systemd-sysv.

This seems like a bug in gconf-gsettings-backend. gconf versions since
2012 need a D-Bus session bus just as much as dconf does: they have a
similar architecture (clients use D-Bus to talk to a server that handles
writes, to provide change notification and avoid write conflicts),
except that GConf stores many tiny XML files and has a lot more D-Bus
round-trips (because in GConf, reads are also done via D-Bus).

I suspect gconf-gsettings-backend should probably not have Provides
on gconf-backend, since it won't be used unless you specifically ask
for it with GSETTINGS_BACKEND=gconf (because GConf is obsolete, and
automatically storing settings in it would invite apparent data loss
when you install dconf-gsettings-backend, GLib prefers that one, and
the settings in GConf are no longer read) so the practical effect is
that your settings are probably not stored.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Simon McVittie-7
In reply to this post by Jonas Smedegaard-2
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 | Threaded
Open this post in threaded view
|

Re: Building GTK programs without installing dconf-service?

Raphael Hertzog-3
On Fri, 16 Aug 2019, Simon McVittie wrote:
> 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,

FWIW, I don't think there's any such consensus... that whole thread seems
very futile to me and I almost skipped it right from the start because
it was started by someone unhappy with systemd who should just use chroots
or containers or VM to build and accept to have systemd-sysv installed in
a build chroot (even if he doesn't want to have systemd as its init on
his server).

I'm pretty happy that you are always willing to investigate thoroughly and
see if we can improve, but you justified all the relationships properly
and I think that we can stop here.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

12