From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: "OE Core \(openembedded-core@lists.openembedded.org\)"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCHv2 1/1] Revert "useradd.bbclass: remove user/group created by the package in clean* task"
Date: Thu, 14 Apr 2016 11:40:55 +0100 [thread overview]
Message-ID: <1460630455.9308.168.camel@linuxfoundation.org> (raw)
In-Reply-To: <1460564978.9308.95.camel@linuxfoundation.org>
On Wed, 2016-04-13 at 17:29 +0100, Richard Purdie wrote:
> There is a comparatively neat way we could use pkgdata to track the
> provider of a given user, specifically:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/w
> ip
> &id=5cd646ea185eaafaa341f26310f2eddc75766175
>
> The above is a quick patch I've just put together which illustrates
> what could be done so that the user gets better warnings about
> conflicting users. It needs cleaning up but thought it worth sharing
> now as if might give some ideas.
>
> This is in keeping with how bitbake detects multiple providers of the
> same thing.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip
&id=a362e6da0eec1f7a7d4db19d47f16b1c729562ba
is an improved version.
> > 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).
>
> oe-selftest would be the place to add something like this, see the
> /meta/lib/oeqa/selftest directory. We could add some test useradd
> recipes to meta-selftest.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip
&id=23134a7d837bc7985ba8e7069d405913c2055a04
is a really simplistic new selftest for useradd. It does however test
the bug the original patch fixes. There are clearly a much wider range
of things it could test, I just wanted to show this isn't hard.
Cheers,
Richard
next prev parent reply other threads:[~2016-04-14 10:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 13:18 [PATCHv2 0/1] Revert cleaning of users/groups Peter Kjellerstedt
2016-04-12 13:18 ` [PATCHv2 1/1] Revert "useradd.bbclass: remove user/group created by the package in clean* task" Peter Kjellerstedt
2016-04-12 13:34 ` Otavio Salvador
2016-04-12 14:54 ` Richard Purdie
2016-04-12 16:35 ` Otavio Salvador
2016-04-12 17:28 ` Peter Kjellerstedt
2016-04-13 11:05 ` Richard Purdie
2016-04-13 15:14 ` Peter Kjellerstedt
2016-04-13 16:04 ` Maxin B. John
2016-04-13 16:29 ` Richard Purdie
2016-04-14 10:40 ` Richard Purdie [this message]
2016-04-14 11:46 ` Peter Kjellerstedt
2016-04-14 11:50 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1460630455.9308.168.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--cc=peter.kjellerstedt@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.