Pkg xen devel - Feb 2019 - [PATCH 06/13] sysconfig.xencommons.in: Strip and debianize

Hans van Kranenburg writes ("[PATCH 06/13] sysconfig.xencommons.in: Strip
and debianize"):
> Strip all options that are for stuff we don't ship, which is 1)
> xenstored as stubdom and 2) xenbackendd, which seems to be dead code
> anyway. [1]
> 
> It seems useful to give the user the option to revert to xenstored
> instead of the default oxenstored if they really want.
> 
> In order to configure this, XENSTORED in here needs to contain the name
> without a path, which is different than how the upstream file suggests
> to use it.
> 
> However, we don't want to put a version-specific path in here (the user
> keeps the config file on upgrades if it's changed, and then will end up
> with a path to a non-existing binary). Also, alternatively,
> /usr/sbin/oxenstored and /usr/sbin/xenstored could be used, but those
> are symlinks to xen-utils-wrapper and not the actual binary, and I think
> the test using start-stop-daemon to see if it's already running would
> fail to detect it's the same as e.g. /usr/lib/xen-4.11/bin/oxenstored.
> At least, it all sounds very fragile. :|
Thanks.  This LGTM (for the Debian package).

Acked-by: Ian Jackson <ijackson at chiark.greenend.org.uk>
^ for Debian, not upstream
> -## Default: Not defined, xenbackendd debug mode off
> -#
> -# Running xenbackendd in debug mode
> -#XENBACKENDD_DEBUG=[yes|on|1]
We might want this if we ship the driver domains init script too.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   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.

On 2/12/19 6:10 PM, Ian Jackson wrote:
> Hans van Kranenburg writes ("[PATCH 06/13] sysconfig.xencommons.in:
Strip and debianize"):
>> Strip all options that are for stuff we don't ship, which is 1)
>> xenstored as stubdom and 2) xenbackendd, which seems to be dead code
>> anyway. [1]
>>
>> It seems useful to give the user the option to revert to xenstored
>> instead of the default oxenstored if they really want.
>>
>> In order to configure this, XENSTORED in here needs to contain the name
>> without a path, which is different than how the upstream file suggests
>> to use it.
>>
>> However, we don't want to put a version-specific path in here (the
user
>> keeps the config file on upgrades if it's changed, and then will
end up
>> with a path to a non-existing binary). Also, alternatively,
>> /usr/sbin/oxenstored and /usr/sbin/xenstored could be used, but those
>> are symlinks to xen-utils-wrapper and not the actual binary, and I
think
>> the test using start-stop-daemon to see if it's already running
would
>> fail to detect it's the same as e.g.
/usr/lib/xen-4.11/bin/oxenstored.
>> At least, it all sounds very fragile. :|
> 
> Thanks.  This LGTM (for the Debian package).
> 
> Acked-by: Ian Jackson <ijackson at chiark.greenend.org.uk>
> ^ for Debian, not upstream
> 
>> -## Default: Not defined, xenbackendd debug mode off
>> -#
>> -# Running xenbackendd in debug mode
>> -#XENBACKENDD_DEBUG=[yes|on|1]
> 
> We might want this if we ship the driver domains init script too.
AFAIU from that [1] I linked, that would mean running devd and not
xenbackendd?

K

Hans van Kranenburg writes ("Re: [PATCH 06/13] sysconfig.xencommons.in:
Strip and debianize"):
> AFAIU from that [1] I linked, that would mean running devd and not
> xenbackendd?
Erk.  Yes, you are right.  I think this hunk is obsolete upstream too
then.  Perhaps its removal should be made into patch for upstream ?

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   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.