On Tue, Aug 20, 2013 at 11:44 AM, Ian Kent <raven@xxxxxxxxxx> wrote: > On Tue, 2013-08-20 at 11:23 +0800, Ian Kent wrote: >> On Mon, 2013-08-19 at 14:23 +0800, Lan Yixun (dlan) wrote: >> > those patches are very trivial changes which only instroduce a new --with-systemdsystemunitdir option >> > to better control where we should install system unit file to >> > >> > 1) seperate --with-systemd opiton, but been kept now for future use (but it's useless now) >> > 2) add new option --with-systemdsystemunitdir to manage the path where unit file will be installed >> > 3) --with-systemd and --with-systemdsystemunitdir are two seperate option, so unit can be installed even systemd support is not enabled. >> > >> > downstream discussion: https://bugs.gentoo.org/show_bug.cgi?id=479492 >> > >> > let me know whether this looks good to you.. >> >> Looks OK but I'll need to spend some time on it in case it conflicts >> with downstream usage I already have. > > After a very quick initial look .... > > It appears that the change does two things. > > Defines WITH_SYSTEMD for subsequent use, although applications usually > don't need to know if they are being managed by systemd. Do you know of > any cases where that is important? > No, no cases I know of, So, I leave you to decide whether to keep it or not > And changes the original --with-systemd configure option to > --with-systemdsystemunitdir adding the ability to specify a unit > directory explicitly. > > Why is it worthwhile changing the configure option as part of this > change? > > Ian > > As talked with gentoo @systemd team, it's conventional to use "--with-systemdsystemunitdir"[1] and I think it's would be slight better/explicitly to pass the unit directory via --with-systemdsystemunitdir=/my/unit/dir/?current logic is "--with-systemd systemddir=/my/unit/dir/" I would have no problem if you insist not to change anyway.. [1] https://bugs.gentoo.org/show_bug.cgi?id=479492#c11 -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html