On Fri, Nov 4, 2016 at 7:09 AM, David Sommerseth <sl+us...@lists.topphemmelig.net> 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
