On 11/04/2013 07:39 PM, Richard Purdie wrote:
On Mon, 2013-11-04 at 17:56 +0800, Hongxu Jia wrote:
Change in V2: The fourth patch fixed the QA Issue on udev, it was missed on
previous version.
//Hongxu
The following changes since commit f3541226b8b1187e79dec0f6f9f3c58cedf9ac9b:
bitbake: hob: do not display the "Package list may be incomplete!" dialog
(2013-11-01 17:59:31 +0000)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib hongxu/fix-qa-issue
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-qa-issue
Hongxu Jia (5):
insane.bbclass: support to skip unsafe references in binaries qa
check.
kmod: fix QA issue
udev: fix QA issue
udev: fix QA issue
nfs-utils: fix QA issue
Last time these warnings came up I asked for a clear plan about what
needed to live in / and what needed to live in /usr and how we were
going to fix things once and for all (or forget this idea).
Where is the plan? Why is it ok to just ignore these particular
warnings?
Cheers,
Richard
Hi Richard,
I want to propose the following solution for this unsafe reference issue.
The solution is based on the following two principles.
1. With /usr on a seperate partition, system should boot up without any error.
2. Without /usr, system should be able to boot into single user mode without
any error.
When a QA warning about unsafe references is encountered, the above two
principles,
together with FHS, are taken into consideration before making a decision.
For example, libkmod is moved to /lib because /lib/udevd requires it; libgudevd
is moved to /usr/lib because it's a GObject wrapper for libudev and it's
obviously
not necessary for booting into single user mode.
The final goals of the solution:
1. Performing a world build doesn't report any warning about unsafe references.
2. System can boot into runlevel 5 without any error if /usr is on another
partition.
3. System can boot into single user mode without any error even if /usr is
missing.
Patches of this solution have been sent to this mailing list.
Best Regards,
Chen Qi
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
