<div dir="auto">This library may be private however this does not mean it should be hidden in a dedicated path. But I guess its better to lower qa guards then carry a patch for life</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 13, 2016 7:20 AM, "Mark Asselstine" <<a href="mailto:mark.asselstine@windriver.com">mark.asselstine@windriver.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Monday, December 12, 2016 9:17:14 PM EST Burton, Ross wrote:<br>
> On 12 December 2016 at 20:51, Mark Asselstine <<a href="mailto:mark.asselstine@windriver.com">mark.asselstine@windriver.com</a><br>
> > wrote:<br>
> ><br>
> > I think the discussion I pointed to in the commit log closes the door on<br>
> > any<br>
> > such change. Specific the comment from Lennart --<br>
> > <a href="https://github.com/systemd/systemd/issues/3810#issuecomment-235290526" rel="noreferrer" target="_blank">https://github.com/systemd/<wbr>systemd/issues/3810#<wbr>issuecomment-235290526</a><br>
> ><br>
> > They don't want the library to be found in the default search path, they<br>
> > want<br>
> > to maintain this as a "hidden, internal resource".<br>
><br>
> Oh if it's an implementation detail of systemd and not a user-facing<br>
> library then I can see their argument I guess.<br>
><br>
> Don't agree with it though. But, the point is that as long as the parts of<br>
> systemd that could realistically be multilibd are in $libdir then this<br>
> isn't a problem.<br>
<br>
</div>It is definitely an internal infra item for systemd and not seen as a 'public'<br>
library so I think we are best to run with it. I am with you that I don't<br>
necessarily agree with it. Khem, does this satisfy your concerns?<br>
<br>
Mark<br>
<br>
><br>
> Ross<br>
<br>
<br>
</blockquote></div><br></div>