[CentOS] Would this be considered a packaging bug?

[Alice Wonder]

On 02/25/2017 07:27 AM, Alice Wonder wrote:
> On 02/25/2017 06:33 AM, Alice Wonder wrote:
>> On 02/25/2017 06:12 AM, Johnny Hughes wrote:
>>> On 02/25/2017 06:52 AM, Alice Wonder wrote:
>>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=861692
>>>>
>>>> The source RPM there uses
>>>>
>>>> %if 0%{?rhel}
>>>> # not upstreamed
>>>> Patch500: 0001-disable-libe-book-support.patch
>>>> Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
>>>> Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
>>>> Patch503: 0001-impl.-missing-function.patch
>>>> %endif
>>>>
>>>> (and more than just those) resulting in those patches not being
>>>> included
>>>> in the src.rpm because the rpm was not built on rhel/centos.
>>>>
>>>> My understanding was that platform specific patches were suppose to
>>>> have
>>>> the %if macro where the patch is applied, but should not be where the
>>>> source for the patch is defined.
>>>>
>>>> Been a long time since I was a fedora packager so I don't know what
>>>> current packaging guidelines are, but that just seems wrong.
>>>>
>>>> Is it wrong?
>>>
>>> It depends .. in the Red Hat world, this is used so that patches are
>>> applied on RHEL but not on Fedora.  That is the purpose of that patch.
>>> The RHEL team added something to that patch for RHEL that is different
>>> than Fedora.
>>>
>>> So, if built on Fedora, those patches are not installed.  Why would that
>>> be a problem?
>>>
>>>
>>
>> Ouch, looking through the spec file it appears that it doesn't use the
>> normal %patch mechanism to apply patches. Looks like a change in RPM
>> itself that I am not very fond of.
>>
>> It appears to use a git command to apply patches from some kind of a
>> patch macro, and apparently with sources too.
>>
>> It's just my opinion but I am becoming less and less fond of RPM - just
>> like I became less and less fond of GNOME which I use to really love.
>>
>> Guess I now know how dad felt when all the AIX servers he managed
>> started switching to that new-fangled Linux operating system...
>>
>> _______________________________________________
>
> Applying: installation fix
> Applying: never run autogen.sh
> error: patch failed: Makefile.in:14
> error: Makefile.in: patch does not apply
> Patch failed at 0002 never run autogen.sh
> The copy of the patch that failed is found in:
>    /builddir/build/BUILD/libreoffice-5.3.1.1/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --resolved".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> error: Bad exit status from /var/tmp/rpm-tmp.c4c5hh (%prep)
>
> -=-=-
> That's progress, eh? ;)
>
> git is a source management tool. It's not a build tool. Ah well.
>
> _______________________________________________

Ouch some of the patches are failing because I took them from CentOS 
src, because they were missing from Fedora source.rpm - it appears that 
in the newer Libre Office src.rpm - the rhel specific patches that are 
in the spec file but are not in the src.rpm share the same filename but 
different content than in the CentOS version of the older libreoffice.

I'm guessing it is possible those patches haven't even been ported to 
the newer LibreOffice - I'll try building without them, but that is what 
was wrong with the never run autogen patch.

I installed the CentOS src.rpm to get missing files and that also 
over-wrote some of the more current Fedora sources with the same name.

Guess using GIT means version control in filenames themselves is no 
longer being used.

Well in my quest to build rawhide libreoffice in CentOS 7 - I only have 
one more bad patch to deal with, I will try building without it.

I don't like RPM using git to apply patches though. It was much easier 
when I could just look at the failed hunks to see what went wrong.