<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 3 July 2015 at 10:34, Huang, Jie (Wind River) <span dir="ltr"><<a href="mailto:jackie.huang@windriver.com" target="_blank">jackie.huang@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p><span style="color:black">I see your point, I think we can make the empty PN rdepends on PN-dev(but the dev-deps QA check need to be skipped),
<u></u><u></u></span></p>
<p><span style="color:black">then when user try to add PN, PN-dev will also be installed, so it’s not an useless empty package.</span></p></blockquote><div><br></div><div>bigreqsproto is development headers. Therefore its in the bigreqsproto-dev package. This is not hard to understand, nor should we start filling the feeds up with empty packages just to please users who can't verify the package names.</div><div><br></div><div>Didn't we have this discussion a few months ago? There are some recipes where PN not existing is unusual (avahi was a good example, and I had a partial branch to fix that), but for recipes which entirely consist of development files, there only being a development package is reasonable and predictable.</div><div><br></div><div>(If I *had* to do this, I'd have RPROVIDES_${PN}-dev += ${PN})</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p><span style="color:black">I see that openssh has similar situation, PN is allowed empty, but it rdepends on “${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen”.</span></p></blockquote></div>That's a different use case entirely: pulling in the entire SSH suite in a single package whilst still allowing resource-constrained or secure systems to pull in only the parts they want.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>