Bug 3097 - rpmbuild treats patches as URLs
: rpmbuild treats patches as URLs
Status: RESOLVED NOTABUG
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 19:13 MSK by Dmitry
Modified: 2013-11-08 11:59 MSK (History)
1 user (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry 2013-11-07 19:13:38 MSK
Description of problem:

rpmbuild treats patches as URL and tries to download them, but it always fails so it creates empty patches in rpmbuild/SOURCES and then fails to apply them.
Comment 1 Denis Silakov 2013-11-07 19:26:14 MSK
Not "always", but only if patches are missing from the SOURCES folder.

In this case yes, rpmbuild will try to download patch. You can specify URL for the patch in the same way as for sources, e.g.:

Patch: https://abf.rosalinux.ru/import/fastdup/raw/master/fastdup-0.3-install-path.patch

And it will be automatically downloaded.

If it fails, it honestly reports something like this:

error: Fetching Patch0 failed: Unknown or unexpected error
error: Missing Patch0: fastdup-0.3-install-path.patch: No such file or directory

and stops the build.

But as a side effect of wget usage, in case of fail an empty file is created. And if you start the build once again, rpmbuild will think that you have the patch downloaded.

So the issue with empty patch failed to apply can be met only if you ignore the download error and manually restart the build. And I don't think this is a good behavior:) Surely, it would benice to eliminate creation of empty patch, but I consider this as a minor issue.
Comment 2 Dmitry 2013-11-07 19:36:19 MSK
No, right behaviour is following: rpmbuild must copy patch file to SOURCES itself. It WAS earlier so, but now it tries to download somepatch.patch. Fo example, if patch is specified in spec-files:

Patch1: somepatch.path


Actual behaviour:
rpmbuild tries to download somepatch.patch.


Expected true behaviour:
rpmbuild copies somepatch.patch from local folder where spec-file is located to a SOURCES. User should never copy files to SOURCES itself!!!
Comment 3 Dmitry 2013-11-07 19:40:21 MSK
And you are right that if a real URL is specified in Patch: tag (starting from ftp://, http://) then rpmbuild should download patches from remote server. But it must treat somepatch.patch as local file
Comment 4 Denis Silakov 2013-11-07 20:38:14 MSK
(In reply to comment #2)
> No, right behaviour is following: rpmbuild must copy patch file to SOURCES
> itself. It WAS earlier so, but now it tries to download somepatch.patch. 

Yes, the behavior was changed after migrating from internal implementation of file downloader to wget. This was done due to the fact that rpmbuild often failed to download files from Internet using its internal mechanism.

> Expected true behaviour:
> rpmbuild copies somepatch.patch from local folder where spec-file is located
> to a SOURCES. User should never copy files to SOURCES itself!!!

Really? http://goo.gl/qVKkjx

And users usually don't build packages, they leave this task to maintainers:)

Anyway, you can easily turn back the old behavior by commenting out "__urlgetfile" macro in /usr/lib/rpm/macros.d/mandriva file.
Comment 5 Dmitry 2013-11-07 20:53:41 MSK
(In reply to comment #4)
> Yes, the behavior was changed after migrating from internal implementation
> of file downloader to wget. This was done due to the fact that rpmbuild
> often failed to download files from Internet using its internal mechanism.

If the behaviour is changed then it is a regression that is a real bug.


> Really? http://goo.gl/qVKkjx

That is *not* an official documentation of rpmbuild.

> And users usually don't build packages, they leave this task to maintainers:)

maintainers are the *users* of rpmbuild.
Comment 6 Denis Silakov 2013-11-08 09:00:34 MSK
(In reply to comment #5)
> (In reply to comment #4)
> > Yes, the behavior was changed after migrating from internal implementation
> > of file downloader to wget. This was done due to the fact that rpmbuild
> > often failed to download files from Internet using its internal mechanism.
> 
> If the behaviour is changed then it is a regression that is a real bug.
> 
> 
> > Really? http://goo.gl/qVKkjx
> 
> That is *not* an official documentation of rpmbuild.

And where is the "official" one that says something about automatic copying of patches to SOURCES folder? 

ROSA wiki describes the way used by all maintainers for almost 20 years. You can read Fedora description if you think that ROSA one is wrong: https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview
(quote from there: "If you need to patch the files after they've been uncompressed, you should edit the files and save their differences as a "patch" file in your ~/rpmbuild/SOURCES director").

> > And users usually don't build packages, they leave this task to maintainers:)
> 
> maintainers are the *users* of rpmbuild.

Surely, but I believe that they should be more skilled in building packages then original users.

Again - feel free to edit your /usr/lib/rpm/macros.d/mandriva file and either disable or modify "__urlgetfile" macro in the way you like.
Comment 7 Dmitry 2013-11-08 09:59:55 MSK
OK, I have to copy patches, sources. I don't understand why it can't be done by rpmbuild. Instead of type one command in console, I have to open spec file, parse file, open firefox, copy URLs to firefox, download files (number of files may be more 100), copy them to SOURCES and then run rpmbuild. That is really NOT user-friendly.
Comment 8 Denis Silakov 2013-11-08 11:30:43 MSK
Well, I don't say that rpmbuild is perfect and there are no ways to improve it. The actual reason for switching to wget (or other external downloader) is that native rpm implementation of network download is semi-broken in Desktop Fresh.
Up to now we didn't find the reason of this (the same rpm in Marathon works fine), so we have switched to external downloader.

The proper fix would to fix internal rpm mechanism, but this task requires some investigations and up to now we didn't find time to do it.
Comment 9 Denis Silakov 2013-11-08 11:59:02 MSK
Just for experiment, you define __urlgetfile in /usr/lib/rpm/macros.d/mandriva in the following way:

%__urlgetfile(url, dest) %(if [ -e %1 ] ; then cp %1 %2; else wget %1 -O %2 || (rm -f %2 && exit 1) ; fi)

This solution seems to work for me without breaking anything else. If it works for you, I can modify __urlgetfile in our rpmbuild.