[OE-core] [PATCHv2 1/1] Revert "useradd.bbclass: remove user/group created by the package in clean* task"

[Peter Kjellerstedt]

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> Sent: den 13 april 2016 13:05
> To: Peter Kjellerstedt; Otavio Salvador
> Cc: OE Core (openembedded-core at lists.openembedded.org)
> Subject: Re: [OE-core] [PATCHv2 1/1] Revert "useradd.bbclass: remove
> user/group created by the package in clean* task"
> 
> I am pretty frustrated with this thread. The reasons are perhaps not
> immediately obvious though.
> 
> The issue is that there are only a limited number of people who
> actually dive in and try and fix some of the underlying "core
> architecture" bugs. There is what I believe to be a pretty good patch
> here which does fix real world issues which have been reported into the
> bugzilla (its related to at least two bug reports). As such it has been
> seen as a bugfix. Its now clear it does have some side effects which
> weren't envisaged, some causing issues for a small number of meta-oe
> recipes, the others breaking a companies internal code.
> 
> Otavio wants it deferred to 2.2, Peter wants it abandoned entirely.
> 
> If I revert this, Peter is then happy and has zero incentive to do
> anything further. The pressure is still on the reopened bugs to try and
> fix this somehow and falls back to the usual suspects. There is a real
> world usability problem there.

Hold your horses. I definitely see the problem the change tried to 
address as one that needs to be fixed, and I am already looking at 
how to solve this properly (currently based on my second suggested 
solution). However, I do not know if I can fix it in time for Krogoth. 
Which is why I agree with Otavio that the change was introduced too 
late in the process, especially as it causes breakage for existing 
users.

> In a single isolated case, fine, we'd figure a way through this. I
> think I'm so frustrated as we see this all the time. Making a change to
> the core architecture is hard and gets ever harder, then we wonder why
> we don't have contributors. Part of this is having so many different
> workflows and corner cases.
> 
> I have pushed very hard to have more test cases, then its easier to
> determine if a patch causes regressions. Again though, few people are
> contributing to them outside the usual suspects.

Here I must show my lack of knowledge. How and where should I go about 
adding a regression test that verifies the support for that multiple 
recipes can add the same user/group? Since this does not test a 
specific recipe, but rather a part of the build framework, I do not 
know if, e.g., ptest is applicable (of which I have no experience 
either).

> I'm therefore starting to think the correct answer to this thread is
> simply this:
> 
> The patch doesn't break any of the current regression tests. If you
> have use cases like this you care about, you really should make sure we
> have test coverage for them, else you run the risk of exactly the
> problem we have here.
> 
> I haven't honestly decided what to do but this latter conclusion is
> very tempting from where I'm sitting...
> 
> Cheers,
> 
> Richard

//Peter