On Fri, Nov 4, 2016 at 7:09 AM, David Sommerseth
<[log in to unmask]> wrote:
> On 04/11/16 11:59, David Sommerseth wrote:
>> On 04/11/16 11:13, Todd Chester wrote:
>>> On 11/03/2016 04:38 AM, Nico Kadel-Garcia wrote:
>>>
>>>> Or, you could try what I do for backports. Install "mock", add
>>>> yourself to the "mock" group, and run:
>>>>
>>>>           mock -r epel-7-x86_64 krusader-2.5.0-1.fc26.src.rpm
>>>>
>>>> Then install RPMs from /var/lib/mock/ or /var/cache/mock/
>>>
>>> What is "mock"?
>>
>> That is the a build tool which does all the RPM builds inside a fresh,
>> autocreated chroot to ensure you get a clean build.  If the spec file is
>> lacking needed dependencies, the build will fail.  Which again helps
>> preventing creating an RPM package including dependencies which just
>> happened to be installed.
>
> Sorry, that was a confusing sentence.  What I tried to say is:
>
> If you had installed qt5-qtbase on your box, but it was not listed in
> the Requires: section of the RPM .spec file, rpmbuild would happily
> build the RPM.  But if you install this RPM on a system where qt5-qtbase
> would not be installed, it would fail.

RPM is pretty good about detecting library dependencies at build time
and publishing them to installation, so a "yum install" would usually
get this.

> Further in the same scenario, if you had qt5-qtbase installed and then
> installs your own built RPM it works fine.  If a user then uninstalls
> qt5-qtbase it will happen without any alarms - and your own built RPM
> will fail to run again.
>
> Using mock, it will complain at build time that a Requires: dependency
> is lacking.  And you would not get an RPM out of mock before this is
> fixed.  And once fixed, yum install on that RPM will automatically pull
> in the qt5-qtbase dependency.  If the user then tries to uninstall
> qt5-qtbase later on, it will also want to uninstall your own built RPM
> due to the dependency chain being correct.

At build time it will notice that a "BuildRequires" is lacking, not a
"Requires". "Requires" comes up at installation time. One of the
things mock helps with is ensuring that locally updated libraries, or
out of date or third party libraries, do not wind up as out-of-band or
incompatible dependencies for your locally built RPM, especially
dependencies that exist only on your local machine and are not in any
published RPM. And some "configure" tools insert features, or disable
features, based on local libraries being available. RPM authors spend
a lot of time making sure that *only* the components they need for
compilation are present, to avoid this, and "mock" is very helpful. In
turn, it helps ensure that those components *do* get detected and
listed as BuildRequires:.

I went through just this building "chefdk" for SL 5. It required an
updated version of ruby to compile its own internal ruby, and that
meant replacing the system ruby with a very funky 3rd party backport
that needed *not* to be left in place. Using "mock", I was able to put
that ruby in a separate yum repository and let mock build in a chroot
cage without messing with the system version of ruby.

If you're on an SL 6 box, it can be really helpful just to install
mock, make sure you are in the "mock" group to enable privileges, and
type "mock whatever.src.rpm" By default it builds software for your
local working OS. Admittedly, it's using CentOS and EPEL upstream
repositories, but if desired you can even make configurations like
"sl-6-x86_64" and point it to your local Scientific Linux mirror,
rather than using the CentOS mirrors. I've done that.

> So using mock will result in far saner packages than just using rpmbuild
> directly.  Using rpmbuild directly is useful though in the beginning, to
> ensure things seems to build fine.  But final packages should always go
> via mock.

Amen. This is why I publish my srpm repositories over at
https://github.com/nkadel/, to allow others to use mock and build
their own dependency chains as needed.

> Another useful tool when you do packaging, is to run .spec file and
> produced RPM files via rpmlint.  This will also provide a good overview
> if the package is in a reasonable shape.
>
>
> --
> kind regards,
>
> David Sommerseth