On Mon, Jul 29, 2019 at 07:14:36PM +, Jim Fehlig wrote:
> On 7/29/19 8:18 AM, Andrea Bolognani wrote:
> > On Mon, 2019-07-29 at 13:17 +0100, Daniel P. Berrangé wrote:
> >> On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote:
> >>> Again IIUC there's nothing really stopping us from
On 7/29/19 8:18 AM, Andrea Bolognani wrote:
> On Mon, 2019-07-29 at 13:17 +0100, Daniel P. Berrangé wrote:
>> On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote:
>>> Again IIUC there's nothing really stopping us from generating
>>> virtqemud*.service from libvirtd*.service.in, or at
On Mon, 2019-07-29 at 13:17 +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote:
> > Again IIUC there's nothing really stopping us from generating
> > virtqemud*.service from libvirtd*.service.in, or at least from
> > a common virtd*.service.in,
On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote:
> On Tue, 2019-07-23 at 17:02 +0100, Daniel P. Berrangé wrote:
> > The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
> > SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
> > .in suffix.
>
On Tue, 2019-07-23 at 17:02 +0100, Daniel P. Berrangé wrote:
> The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
> SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
> .in suffix.
>
> This won't work in future when a single .in unit file can be used to
>
The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
.in suffix.
This won't work in future when a single .in unit file can be used to
generate multiple different units.
Signed-off-by: Daniel P. Berrangé
