How to deal with system-wide state databases

How to deal with system-wide state databases

[Roel Janssen]

Dear Guix,

I've been trying to get the help feature in gparted to work, but it uses
an external program for it called "scrollkeeper".  No problem so far,
because I have a working package for it.

However, Scrollkeeper maintains a database in which all documentation
that is compatible with scrollkeeper is linked, creating a central point
to search for help files.

It all comes down to this invocation:
scrollkeeper-update -p /gnu/store/c9bp09...-scrollkeeper-0.3.14/var/lib/scrollkeeper \
                    -o /gnu/store/xgbvyq...-gparted-0.26.0/share/omf/gparted

The -p option specifies the scrollkeeper database directory.

How should we deal with mechanisms like this?  Should I change the scrollkeeper
database directory per program, so in this case it becomes:
/gnu/store/xgbvyqs...-gparted-0.26.0/var/lib/scrollkeeper

Or can we deal with this in a more cross-package way?

Kind regards,
Roel Janssen

Re: How to deal with system-wide state databases

[Ludovic Courtès]

Hello!

Roel Janssen <roel@gnu.org> skribis:

> How should we deal with mechanisms like this?  Should I change the scrollkeeper
> database directory per program, so in this case it becomes:
> /gnu/store/xgbvyqs...-gparted-0.26.0/var/lib/scrollkeeper
>
> Or can we deal with this in a more cross-package way?

Maybe we could add a profile hook to ‘%default-profile-hooks’ in (guix
profiles)?

Ludo’.

Re: How to deal with system-wide state databases

[Roel Janssen]

Ludovic Courtès writes:

> Hello!
>
> Roel Janssen <roel@gnu.org> skribis:
>
>> How should we deal with mechanisms like this?  Should I change the scrollkeeper
>> database directory per program, so in this case it becomes:
>> /gnu/store/xgbvyqs...-gparted-0.26.0/var/lib/scrollkeeper
>>
>> Or can we deal with this in a more cross-package way?
>
> Maybe we could add a profile hook to ‘%default-profile-hooks’ in (guix
> profiles)?

I think people only need Scrollkeeper when they wish to have the
documentation available in Yelp (GNOME's help browser).  So it only
affects a few people I believe.

Would it then still make sense?  Maybe this hook should only be active
when Yelp is installed in the profile on which the transaction
operates.  Is that possible?

With this construct, I'd have to patch out the 'scrollkeeper-update'
command from the GParted build system.

Kind regards,
Roel Janssen

Re: How to deal with system-wide state databases

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Hello!
>>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> How should we deal with mechanisms like this?  Should I change the scrollkeeper
>>> database directory per program, so in this case it becomes:
>>> /gnu/store/xgbvyqs...-gparted-0.26.0/var/lib/scrollkeeper
>>>
>>> Or can we deal with this in a more cross-package way?
>>
>> Maybe we could add a profile hook to ‘%default-profile-hooks’ in (guix
>> profiles)?
>
> I think people only need Scrollkeeper when they wish to have the
> documentation available in Yelp (GNOME's help browser).  So it only
> affects a few people I believe.

I think documentation is quite useful, in general.  :-)

> Would it then still make sense?  Maybe this hook should only be active
> when Yelp is installed in the profile on which the transaction
> operates.  Is that possible?

Definitely.  For instance, ‘ghc-package-cache-file’ does exactly this
kind of trick.  (It’s not completely satisfying, since we’re simply
matching file names, but it does the job.)

> With this construct, I'd have to patch out the 'scrollkeeper-update'
> command from the GParted build system.

Yes.

Thanks,
Ludo’.

Re: How to deal with system-wide state databases

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hello!
>>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> How should we deal with mechanisms like this?  Should I change the scrollkeeper
>>>> database directory per program, so in this case it becomes:
>>>> /gnu/store/xgbvyqs...-gparted-0.26.0/var/lib/scrollkeeper
>>>>
>>>> Or can we deal with this in a more cross-package way?
>>>
>>> Maybe we could add a profile hook to ‘%default-profile-hooks’ in (guix
>>> profiles)?
>>
>> I think people only need Scrollkeeper when they wish to have the
>> documentation available in Yelp (GNOME's help browser).  So it only
>> affects a few people I believe.
>
> I think documentation is quite useful, in general.  :-)
>
>> Would it then still make sense?  Maybe this hook should only be active
>> when Yelp is installed in the profile on which the transaction
>> operates.  Is that possible?
>
> Definitely.  For instance, ‘ghc-package-cache-file’ does exactly this
> kind of trick.  (It’s not completely satisfying, since we’re simply
> matching file names, but it does the job.)

When I looked into the code and what derivations are actually built in
my profile I noticed 'ghc-package-cache-file' was not among them.  So,
this is actually what I need. :-)

>> With this construct, I'd have to patch out the 'scrollkeeper-update'
>> command from the GParted build system.
>
> Yes.

Great.  So the next step with GParted is to create a
'scrollkeeper-database' hook.  I'm not sure how to do that by looking at
the existing hooks, but I will attempt to create one.

Thanks!

Kind regards,
Roel Janssen

Re: How to deal with system-wide state databases

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:

[...]

>>> With this construct, I'd have to patch out the 'scrollkeeper-update'
>>> command from the GParted build system.
>>
>> Yes.
>
> Great.  So the next step with GParted is to create a
> 'scrollkeeper-database' hook.  I'm not sure how to do that by looking at
> the existing hooks, but I will attempt to create one.

To be clear, you can already provide a GParted package.  The
scrollkeeper hook is orthogonal.

Ludo’.