On 09/21/2016 04:33 AM, Mark Hatle wrote:
On 9/20/16 10:00 AM, Burton, Ross wrote:

On 20 September 2016 at 09:15, Hongxu Jia <hongxu....@windriver.com
<mailto:hongxu....@windriver.com>> wrote:

    -Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org
    +Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org

Considering upstream has explicitly rejected this patch, why should we accept 


I'm confused by what the patch is doing looking at it.

It sounds like from the description there is a bug that without the change,
packages with (intentionally) bad checksums and such are allowed to be 

The bug is caused by a previous patch that enabled nosignature, etc -- because
the comparisons turned out to be backwards.

So really nosignature, etc is already in place -- it's just not working 

What was rejected upstream is the use of nosignature in any context.  RPM5
maintainer believes it is unwise and unsafe to permit uses to install packages
that have failed basic validation.  (I tend to agree.)  Similarly, even being
able to run queries and other operations against them may be dangerous as well.

If command like "rpm5 -qp --nosignature --nodigest <file.rpm>" queries database,
then it would cause rpm5 hang when more than one "rpm5 -qp" is running, so I
fixed the *query* problem, and the *install* problem is not caused by the fix.
Btw., *rpm4* doesn't query database when "rpm -qp file.rpm", if we are going
to use dnf in next release, maybe we can consider using rpm4 as Fedora does.
I did a rough statistics for oe-core's local patches, the winner is rpm, it
has 77 local patches, that's not good for maintaining, and you can imagine that
how many times it surprised us. rpm4 should be more stable than rpm5, I don't
know how many distros use rpm5, I can't access rpm5.org atm, it seems that the
web is down (It was OK yesterday), but widely used distros like Redhat and Suse
uses rpm4, so maybe rpm4 will make our life much more easier, and also for
yocto's user. I think that why we need rpm5 before was because we need use it
to compute the package dependencies, but now we have smartpm, so we don't rely
on that any more.

Here is the recipe list which has more than 10 local patches, and we have 1762
patches atm:
     77 rpm
     59 gcc-5.4
     49 gcc-6.2
     36 ltp
     31 python3
     30 perl
     29 openssl
     28 man
     27 glibc
     24 python
     23 tcp-wrappers-7.6
     23 systemd
     18 busybox
     14 syslinux
     14 python-smartpm
     14 elfutils-0.166
     14 apt
     13 qemu
     13 libtool
     13 gstreamer1.0-plugins-bad
     13 glib-2.0
     13 binutils
     13 bind
     12 coreutils-6.9
     11 valgrind
     11 gdb
     11 dhcp
     11 autoconf
     10 unzip
     10 dpkg
     10 console-tools-0.3.2

If fixing the problem is as simple as reverting the other change -- and that
doesn't cause other problems elsewhere...  I'd rather see that.

We can't revert the patch, it would break packagefeed-stability.bbclass,
we will see the hang


Openembedded-core mailing list

Reply via email to