<servicedir> scanning order

[Yang Chengwei]

On Tue, Jul 16, 2013 at 06:40:29PM +0100, Simon McVittie wrote:
> On 16/07/13 17:41, Joseph Artsimovich wrote:
> > In a system we are developing, we are going to have identically named
> > .service files (with different Exec attribute) in 2 different locations.
> > We want one of those locations to have higher priority than another.
> 
> System or session services, or some third type of bus?
> 
> For session services, you can use the XDG Base Directory specification
> (set $XDG_DATA_HOME and $XDG_DATA_DIRS) to get a well-understood
> precedence order ($XDG_DATA_HOME is most important, then earlier
> ":"-delimited entries in $XDG_DATA_DIRS is more important than later ones).
> 
> For system services, there are already several locations read by default
> (see the source code for details) - perhaps those meet your needs? They
> include /usr/local/share and /usr/share, with /usr/local/share taking
> precedence (at least, it's meant to). They also include the prefix in
> which dbus is installed, and /lib.
> 
> I wouldn't oppose adding /etc/dbus-1/system-services to the search path
> for system services (at the beginning), analogous to
> /etc/systemd/system, if that was considered useful.
> 
> > From dbus manual page it follows that <servicedir> entries are scanned
> > in reverse order they appear in config file:
> > -----------------------
> > <servicedir>
> > Adds a directory to scan for .service files. Directories are scanned
> > starting with the last to appear
> > in the config file (the first .service file found that provides a
> > particular service will be used).
> > -----------------------
> > 
> > Unfortunately my tests show that <servicedir> entries are really scanned
> > in the order they appear in config file.
> > 
> > It looks like either the documentation or implementation needs to be fixed.
> 
> I suspect the implementation shouldn't be changed now: if it's wrong,
> it's likely to have been wrong for several years, so people might be
> relying on it. I'd prefer to fix the documentation to make it match the

This assumes that user always rely on the effect rather than the
document, so this change will supprise some users who rely on what
they learned from document.

From my point of view, only a small group of user may put .service files
in different <servicedir> that provide a same bus name. And those users
can observe this issue. The others may rely on the document, so I'd
prefer to fix the implementation to the document.

--
Thanks,
Chengwei

> implementation. Please open a bug on bugs.freedesktop.org so this
> doesn't get lost.
> 
> Regression tests also gratefully accepted :-)
> 
> Ideally, the documentation would be in terms of (earlier|later)
> <servicedir> entries being considered more authoritative/important than
> (later|earlier) ones - that's the ordering that matters. Whether we read
> least-important-first and overwrite existing entries, or read
> most-important-first and skip services that would conflict with existing
> entries, is an implementation detail.
> 
>     S
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130718/b9eda031/attachment.pgp>