Patchwork Revert "kmod: Use base_libdir for installing libkmod"

login
register
mail settings
Submitter Koen Kooi
Date May 15, 2012, 9:32 a.m.
Message ID <1337074341-12708-1-git-send-email-koen@dominion.thruhere.net>
Download mbox | patch
Permalink /patch/27757/
State Accepted
Commit 7163ebd92a799b8f000b2b6f303b20de468b5f90
Headers show

Comments

Koen Kooi - May 15, 2012, 9:32 a.m.
The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.

This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
---
 meta/recipes-kernel/kmod/kmod_git.bb |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Khem Raj - May 15, 2012, 8:54 p.m.
On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
>
> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.

while this is what I had initially it doesn't go well with kmod living in
/sbin and accessing libraries from /usr due to our QA checks although
I am all for simplifying it where we don't make this check at all.
Richard Purdie - May 17, 2012, 8:29 p.m.
On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
> >
> > This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
> 
> while this is what I had initially it doesn't go well with kmod living in
> /sbin and accessing libraries from /usr due to our QA checks although
> I am all for simplifying it where we don't make this check at all.

I've had requests for it along with a commitment to fix it and patches.
If we decide we don't want this, fine and that will be the case if
patches are not forthcoming to fix the QA issues. I don't think we've
reached that point at this with that yet.

I've decided to accept this patch and "unbreak" meta-oe/udev at the
expense of screwing up OE-Core. I am however still deeply unhappy people
are trying to bypass OE-Core this way and then "blackmail" OE-Core using
breaking meta-oe as a reason. The whole systemd thing has been badly
handled and needs to get fixed properly. I am trying not to make a big
thing about that although I do feel provoked on other issues and its
hard to resist replying in kind.

Cheers,

Richard
Koen Kooi - May 17, 2012, 8:44 p.m.
Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
>>> 
>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
>> 
>> while this is what I had initially it doesn't go well with kmod living in
>> /sbin and accessing libraries from /usr due to our QA checks although
>> I am all for simplifying it where we don't make this check at all.
> 
> I've had requests for it along with a commitment to fix it and patches.
> If we decide we don't want this, fine and that will be the case if
> patches are not forthcoming to fix the QA issues. I don't think we've
> reached that point at this with that yet.
> 
> I've decided to accept this patch and "unbreak" meta-oe/udev at the
> expense of screwing up OE-Core. I am however still deeply unhappy people
> are trying to bypass OE-Core this way and then "blackmail" OE-Core using
> breaking meta-oe as a reason. The whole systemd thing has been badly
> handled and needs to get fixed properly.

What does systemd have to do with this? This is about a broken commit breaking udev 182 for over a week.
If you have issues with systemd, send patches to meta-oe to fix it. Or at least bug reports that are more than the insinuations above.
Richard Purdie - May 17, 2012, 9:02 p.m.
On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote:
> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> > On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
> >> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
> >>> 
> >>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
> >> 
> >> while this is what I had initially it doesn't go well with kmod living in
> >> /sbin and accessing libraries from /usr due to our QA checks although
> >> I am all for simplifying it where we don't make this check at all.
> > 
> > I've had requests for it along with a commitment to fix it and patches.
> > If we decide we don't want this, fine and that will be the case if
> > patches are not forthcoming to fix the QA issues. I don't think we've
> > reached that point at this with that yet.
> > 
> > I've decided to accept this patch and "unbreak" meta-oe/udev at the
> > expense of screwing up OE-Core. I am however still deeply unhappy people
> > are trying to bypass OE-Core this way and then "blackmail" OE-Core using
> > breaking meta-oe as a reason. The whole systemd thing has been badly
> > handled and needs to get fixed properly.
> 
> What does systemd have to do with this?

Why does meta-oe has its own udev recipe? Is systemd related to that at
all?

>  This is about a broken commit breaking udev 182 for over a week.

OE-Core worked fine and the commit fixes QA warnings which are now back.

> If you have issues with systemd, send patches to meta-oe to fix it. Or
> at least bug reports that are more than the insinuations above. 

I looked in the README and followed that to other README files but
couldn't find any indication about what to do with bugs other than write
patches which I obviously don't have.

When will you be sending the patch to fix the QA warning your revert has
introduced? Yes this is a rhetorical question since I've seen your view
on this problem previously.

Cheers,

Richard
Tom Rini - May 17, 2012, 9:16 p.m.
On Thu, May 17, 2012 at 10:02:43PM +0100, Richard Purdie wrote:
> On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote:
> > Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> > 
> > > On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
> > >> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > >>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
> > >>> 
> > >>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
> > >> 
> > >> while this is what I had initially it doesn't go well with kmod living in
> > >> /sbin and accessing libraries from /usr due to our QA checks although
> > >> I am all for simplifying it where we don't make this check at all.
> > > 
> > > I've had requests for it along with a commitment to fix it and patches.
> > > If we decide we don't want this, fine and that will be the case if
> > > patches are not forthcoming to fix the QA issues. I don't think we've
> > > reached that point at this with that yet.
> > > 
> > > I've decided to accept this patch and "unbreak" meta-oe/udev at the
> > > expense of screwing up OE-Core. I am however still deeply unhappy people
> > > are trying to bypass OE-Core this way and then "blackmail" OE-Core using
> > > breaking meta-oe as a reason. The whole systemd thing has been badly
> > > handled and needs to get fixed properly.
> > 
> > What does systemd have to do with this?
> 
> Why does meta-oe has its own udev recipe? Is systemd related to that at
> all?

I would imagine it's part of the tight coupling of parts here, yes.

> >  This is about a broken commit breaking udev 182 for over a week.
> 
> OE-Core worked fine and the commit fixes QA warnings which are now back.

Isn't the rule for QA errors supposed to be that you fix real problems
and tell the automated checks "we know what we're doing, be quiet" ?

All that's happened is that meta-oe has been working as intended and put
in a newer version of a recipe, before oe-core can move to it, and found
problems that need to be addressed.
Paul Eggleton - May 17, 2012, 9:25 p.m.
On Thursday 17 May 2012 14:16:37 Tom Rini wrote:
> All that's happened is that meta-oe has been working as intended and put
> in a newer version of a recipe, before oe-core can move to it, and found
> problems that need to be addressed.

This is where I disagree - IMHO meta-oe should be split such that you can get 
the additional recipes in it without unexpected surprises like critical system 
components (like udev) being up-revved and then breakage resulting. There is 
some work needed to get to this point but we need to keep moving towards it I 
think.

Cheers,
Paul
Otavio Salvador - May 17, 2012, 9:51 p.m.
On Thu, May 17, 2012 at 6:25 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Thursday 17 May 2012 14:16:37 Tom Rini wrote:
>> All that's happened is that meta-oe has been working as intended and put
>> in a newer version of a recipe, before oe-core can move to it, and found
>> problems that need to be addressed.
>
> This is where I disagree - IMHO meta-oe should be split such that you can get
> the additional recipes in it without unexpected surprises like critical system
> components (like udev) being up-revved and then breakage resulting. There is
> some work needed to get to this point but we need to keep moving towards it I
> think.

From time to time it is easier to avoid to work in OE-Core and work in
meta-oe or another layer; udev is no different. It has been update in
meta-oe long time ago and many people use and depends on it.

It is important to state that if OE-Core breaks Meta-OE this is
crticial. It is not Yocto that people use and many active contributors
use Meta-OE so it is important and critical to that people. Seems more
health to the project to give the deserved value to Meta-OE instead of
badmouth it...
Paul Eggleton - May 17, 2012, 10:01 p.m.
On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote:
> It is important to state that if OE-Core breaks Meta-OE this is
> crticial. It is not Yocto that people use and many active contributors
> use Meta-OE so it is important and critical to that people. Seems more
> health to the project to give the deserved value to Meta-OE instead of
> badmouth it...

The sooner people can start using it without fear of it doing unexpected 
things, the sooner people will be able to have more confidence in it and stop 
making negative comments about it. As it stands the way a lot of people treat 
meta-oe is a source of recipes to be copied elsewhere because they feel they 
cannot use the layer as a whole. I think that's a big shame.

Cheers,
Paul
Otavio Salvador - May 17, 2012, 10:11 p.m.
On Thu, May 17, 2012 at 7:01 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote:
>> It is important to state that if OE-Core breaks Meta-OE this is
>> crticial. It is not Yocto that people use and many active contributors
>> use Meta-OE so it is important and critical to that people. Seems more
>> health to the project to give the deserved value to Meta-OE instead of
>> badmouth it...
>
> The sooner people can start using it without fear of it doing unexpected
> things, the sooner people will be able to have more confidence in it and stop
> making negative comments about it. As it stands the way a lot of people treat
> meta-oe is a source of recipes to be copied elsewhere because they feel they
> cannot use the layer as a whole. I think that's a big shame.

Agreed; the nice thing about Free Software is that we can do something
about it; do negative comments help nothing.

Most people on Yocto do not contribute actively to Meta-OE. As
example, you did 12 commits in total to it...
Paul Eggleton - May 17, 2012, 10:21 p.m.
On Thursday 17 May 2012 19:11:20 Otavio Salvador wrote:
> On Thu, May 17, 2012 at 7:01 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote:
> >> It is important to state that if OE-Core breaks Meta-OE this is
> >> crticial. It is not Yocto that people use and many active contributors
> >> use Meta-OE so it is important and critical to that people. Seems more
> >> health to the project to give the deserved value to Meta-OE instead of
> >> badmouth it...
> > 
> > The sooner people can start using it without fear of it doing unexpected
> > things, the sooner people will be able to have more confidence in it and
> > stop making negative comments about it. As it stands the way a lot of
> > people treat meta-oe is a source of recipes to be copied elsewhere
> > because they feel they cannot use the layer as a whole. I think that's a
> > big shame.
> 
> Agreed; the nice thing about Free Software is that we can do something
> about it; do negative comments help nothing.
> 
> Most people on Yocto do not contribute actively to Meta-OE. As
> example, you did 12 commits in total to it...

No, we don't, but that's probably because we have our hands full maintaining 
BitBake and OE-Core (with the help of others in the community, of course). Not 
to mention that when we do enable it on top of OE-Core / Poky without wanting 
to use systemd, it makes a whole raft of changes that usually cause breakage 
of some kind because that configuration is rarely tested. This just makes using 
and contributing to meta-oe harder.

We really do recognise that there has to be a source of recipes outside OE-
Core, and meta-oe is the current place for a lot of those. However there is 
just so much work to be done on BitBake and OE-Core that venturing into meta-
oe as well is something a lot of us don't have time for in our daily work, 
especially with its current state. I do use meta-oe when I'm building stuff at 
home but there I more or less have my hands full maintaining meta-handheld, 
meta-opie and a bunch of other things.

I hope during the current development cycle that I will have time to 
contribute to meta-oe further. I can't make any promises though.

Cheers,
Paul
Phil Blundell - May 17, 2012, 10:22 p.m.
On Thu, 2012-05-17 at 18:51 -0300, Otavio Salvador wrote:
> It is important to state that if OE-Core breaks Meta-OE this is
> crticial. It is not Yocto that people use and many active contributors
> use Meta-OE so it is important and critical to that people. Seems more
> health to the project to give the deserved value to Meta-OE instead of
> badmouth it...

No doubt meta-oe's welfare is indeed critical to those who use it, but
there is a substantial population of oe-core users who don't.

Without wishing to badmouth meta-oe too much, I do get the impression
that its relationship with oe-core is based more on taking than on
giving, and also that meta-oe seems a bit unclear about what exactly its
own mission is.  On the one hand it seems to try to be a sort of
unofficial mod for oe-core which adds newer/older/different versions of
some recipes and adjusts features in others.  On the other hand it seems
to be a repository for recipes which are of general interest but not
quite "core" enough to be in oe-core.  And on the third hand, there
seems to be a view (as Tom alluded to in this thread) that meta-oe
should serve as some sort of staging area for changes which are
ultimately intended for oe-core but perhaps not quite stable enough yet.
As Paul mentioned, the combination of these three things is somewhat
toxic. 

Personally I would like to see the meta-oe folks make a bit more of an
effort to contribute worthwhile improvements back to oe-core (and/or put
them in other layers, as seems to be happening with the systemd bits)
rather than just keeping them as part of the meta-oe monolith
indefinitely.  And, in parallel with that, I think it would make sense
to split meta-oe into three or maybe more separate layers: one which is
purely a collection of "extra" recipes, one which contains all the
policy changes that meta-oe wishes to make compared to what's in
oe-core, and one which is a sort of "oe-core-next", containing changes
which are theoretically candidates for merging into oe-core but for
whatever reason are not quite ready to submit.

p.
Khem Raj - May 17, 2012, 10:50 p.m.
On Thu, May 17, 2012 at 2:51 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
>
> From time to time it is easier to avoid to work in OE-Core and work in
> meta-oe or another layer; udev is no different. It has been update in
> meta-oe long time ago and many people use and depends on it.

if udev has been in meta-oe for long enough and verdict is that its
tested well enough now lets move it to OE-Core.
Andreas Müller - May 17, 2012, 11 p.m.
On Fri, May 18, 2012 at 12:50 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 17, 2012 at 2:51 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>>
>> From time to time it is easier to avoid to work in OE-Core and work in
>> meta-oe or another layer; udev is no different. It has been update in
>> meta-oe long time ago and many people use and depends on it.
>
> if udev has been in meta-oe for long enough and verdict is that its
> tested well enough now lets move it to OE-Core.
>
To make meta-oe less 'frightening' - what are the culprits. Up to now we heard:

* systemd: a layer was born and will be filled (at least by trolls :)
* udev: suggestion above

What else?

Andreas
Koen Kooi - May 18, 2012, 6:19 a.m.
Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote:
>> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
>> 
>>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
>>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
>>>>> 
>>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
>>>> 
>>>> while this is what I had initially it doesn't go well with kmod living in
>>>> /sbin and accessing libraries from /usr due to our QA checks although
>>>> I am all for simplifying it where we don't make this check at all.
>>> 
>>> I've had requests for it along with a commitment to fix it and patches.
>>> If we decide we don't want this, fine and that will be the case if
>>> patches are not forthcoming to fix the QA issues. I don't think we've
>>> reached that point at this with that yet.
>>> 
>>> I've decided to accept this patch and "unbreak" meta-oe/udev at the
>>> expense of screwing up OE-Core. I am however still deeply unhappy people
>>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using
>>> breaking meta-oe as a reason. The whole systemd thing has been badly
>>> handled and needs to get fixed properly.
>> 
>> What does systemd have to do with this?
> 
> Why does meta-oe has its own udev recipe?

Because it's too much trouble to get the updated recipe into oe-core

> Is systemd related to that at all?

No

>> This is about a broken commit breaking udev 182 for over a week.
> 
> OE-Core worked fine

So you say that moving the pkgconfig files from /usr/lib to /lib was fine. Good to know.
Koen Kooi - May 18, 2012, 7:52 a.m.
Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote:
>> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
>> 
>>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
>>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
>>>>> 
>>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
>>>> 
>>>> while this is what I had initially it doesn't go well with kmod living in
>>>> /sbin and accessing libraries from /usr due to our QA checks although
>>>> I am all for simplifying it where we don't make this check at all.
>>> 
>>> I've had requests for it along with a commitment to fix it and patches.
>>> If we decide we don't want this, fine and that will be the case if
>>> patches are not forthcoming to fix the QA issues. I don't think we've
>>> reached that point at this with that yet.
>>> 
>>> I've decided to accept this patch and "unbreak" meta-oe/udev at the
>>> expense of screwing up OE-Core. I am however still deeply unhappy people
>>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using
>>> breaking meta-oe as a reason. The whole systemd thing has been badly
>>> handled and needs to get fixed properly.
>> 
>> What does systemd have to do with this?
> 
> Why does meta-oe has its own udev recipe? Is systemd related to that at
> all?
> 
>> This is about a broken commit breaking udev 182 for over a week.
> 
> OE-Core worked fine and the commit fixes QA warnings which are now back.
> 
>> If you have issues with systemd, send patches to meta-oe to fix it. Or
>> at least bug reports that are more than the insinuations above. 
> 
> I looked in the README and followed that to other README files but
> couldn't find any indication about what to do with bugs other than write
> patches which I obviously don't have.
> 
> When will you be sending the patch to fix the QA warning your revert has
> introduced? Yes this is a rhetorical question since I've seen your view
> on this problem previously.

Those QA checks are a joke. I can fix the QA warnings by moving all kmod binaries to $bindir or $sbindir since binaries in /usr/bin and /usr/bin are exempt from the checks. That would break the split /usr case as well.  These checks are global as well when they only should apply to recipes needed to get /usr mounted.

That's why I consider the current checks misguided and harmfull. As seen from the breakage it allows people to break pkgconfig, which didn't get picked up by QA checks. And then it turns out that you an fix the QA warnings in such a way that it breaks the intent of the warnings.

But this is all a false dillemma, you could have merged Otavio's patch (which I Ack'ed) which supports split /usr and puts the pkgconfig in the right place.
Koen Kooi - May 18, 2012, 8:16 a.m.
Op 18 mei 2012, om 08:19 heeft Koen Kooi het volgende geschreven:

> 
> Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven:
> 
>> On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote:
>>> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
>>> 
>>>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote:
>>>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported.
>>>>>> 
>>>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92.
>>>>> 
>>>>> while this is what I had initially it doesn't go well with kmod living in
>>>>> /sbin and accessing libraries from /usr due to our QA checks although
>>>>> I am all for simplifying it where we don't make this check at all.
>>>> 
>>>> I've had requests for it along with a commitment to fix it and patches.
>>>> If we decide we don't want this, fine and that will be the case if
>>>> patches are not forthcoming to fix the QA issues. I don't think we've
>>>> reached that point at this with that yet.
>>>> 
>>>> I've decided to accept this patch and "unbreak" meta-oe/udev at the
>>>> expense of screwing up OE-Core. I am however still deeply unhappy people
>>>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using
>>>> breaking meta-oe as a reason. The whole systemd thing has been badly
>>>> handled and needs to get fixed properly.
>>> 
>>> What does systemd have to do with this?
>> 
>> Why does meta-oe has its own udev recipe?
> 
> Because it's too much trouble to get the updated recipe into oe-core

And I admit that is not necessarily a bad thing. I would go as far as saying that for recipes like udev it's a good thing. OE-core has seen too many upgrades for the sake of upgrades that were only build tested.
Richard Purdie - May 18, 2012, 10:29 a.m.
On Fri, 2012-05-18 at 09:52 +0200, Koen Kooi wrote:
> Op 17 mei 2012, om 23:02 heeft Richard Purdie het vo
> Those QA checks are a joke. I can fix the QA warnings by moving all
> kmod binaries to $bindir or $sbindir since binaries in /usr/bin
> and /usr/bin are exempt from the checks. That would break the
> split /usr case as well.  These checks are global as well when they
> only should apply to recipes needed to get /usr mounted.
> 
> That's why I consider the current checks misguided and harmfull. As
> seen from the breakage it allows people to break pkgconfig, which
> didn't get picked up by QA checks. And then it turns out that you an
> fix the QA warnings in such a way that it breaks the intent of the
> warnings.

So we need to improve the QA checks, no argument here.

> But this is all a false dillemma, you could have merged Otavio's patch
> (which I Ack'ed) which supports split /usr and puts the pkgconfig in
> the right place.

I likely still will but I was worried when he replied saying it still needed more
testing. I took your reply to the consolidated pull request to refer to
your patch.

Cheers,

Richard
Koen Kooi - May 18, 2012, 10:37 a.m.
Op 18 mei 2012, om 12:29 heeft Richard Purdie het volgende geschreven:

> On Fri, 2012-05-18 at 09:52 +0200, Koen Kooi wrote:
>> Op 17 mei 2012, om 23:02 heeft Richard Purdie het vo
>> Those QA checks are a joke. I can fix the QA warnings by moving all
>> kmod binaries to $bindir or $sbindir since binaries in /usr/bin
>> and /usr/bin are exempt from the checks. That would break the
>> split /usr case as well.  These checks are global as well when they
>> only should apply to recipes needed to get /usr mounted.
>> 
>> That's why I consider the current checks misguided and harmfull. As
>> seen from the breakage it allows people to break pkgconfig, which
>> didn't get picked up by QA checks. And then it turns out that you an
>> fix the QA warnings in such a way that it breaks the intent of the
>> warnings.
> 
> So we need to improve the QA checks, no argument here.

Would a new, additional check for /lib/pkgconfig/*.pc make sense?

> 
>> But this is all a false dillemma, you could have merged Otavio's patch
>> (which I Ack'ed) which supports split /usr and puts the pkgconfig in
>> the right place.
> 
> I likely still will but I was worried when he replied saying it still needed more
> testing. I took your reply to the consolidated pull request to refer to
> your patch.

I was indeed very unspecific there, my apologies.

regards,

Koen

Patch

diff --git a/meta/recipes-kernel/kmod/kmod_git.bb b/meta/recipes-kernel/kmod/kmod_git.bb
index d9c4d8b..fd38d87 100644
--- a/meta/recipes-kernel/kmod/kmod_git.bb
+++ b/meta/recipes-kernel/kmod/kmod_git.bb
@@ -3,7 +3,7 @@ 
 
 require kmod.inc
 
-PR = "${INC_PR}.1"
+PR = "${INC_PR}.2"
 
 PROVIDES += "module-init-tools-insmod-static module-init-tools-depmod module-init-tools"
 RPROVIDES_${PN} += "module-init-tools-insmod-static module-init-tools-depmod module-init-tools"
@@ -16,7 +16,7 @@  RCONFLICTS_libkmod2 += "module-init-tools-insmod-static module-init-tools-depmod
 # autotools set prefix to /usr, however we want them in /bin and /sbin
 bindir = "${base_bindir}"
 sbindir = "${base_sbindir}"
-libdir = "${base_libdir}"
+# libdir = "${base_libdir}"
 
 do_install_append () {
         install -dm755 ${D}${base_bindir}