On 09/04/16 10:54, Jacco Ligthart wrote:
Hi Mark,
mock is a wrapper around rpmbuild. basically it'll create a chroot to
build in, populate that with all the build dependencies needed for the
build at hand and then run rpmbuild in there.
What I like about it is that it is a repeatable process. sometimes RPMS
build differently if extra things are installed. hmm this is not a clear
sentence, let's go for an example:
Suppose a piece of software that could do something useful with LDAP,
but LDAP is not mandatory for the working of the software. The
developers of the software made a test in the configure stage, if LDAP
present, include that in this build, if not not.
bottom line is here that the result of your rpm building might differ if
you had LDAP installed or not.
downside of mock is that for every build it first destroys the chroot,
unpacks a clean one and installs dependencies. All-in-all, this takes
30-60 seconds for every rpm you want to build. For the 'simpler' RPMS, I
guess that the majority of the time is used in this stage. (same goes
for most of the failures)
And this is where I am reminded that it would be _really_ nice if
somebody were to make mock zfs aware, in the same way that docker is zfs
aware.
Current process, assuming it's not the first build (i.e. there is a root
cache tarball already):
- rm -rf /var/lib/mock/<distro>
- tar -C /var/lib/mock -zxf <path-to-cache-tarball>
Needless to say, this is slow and requires craploads of disk I/O, which
is very much _not_ what you want in the situation where the majority of
machines might still have SD card based storage (Back in the EL6 days I
was running /var/lib/mock on NFS which was more bearable but some
packages suffered FTBFS due to tests failing when they are built on NFS).
ZFS process, assuming the basic chroot was build and snapshotted,
equivalent of having a tar ball cache:
- zfs destroy poolname/mock_fs_name
- zfs clone poolname/mock_cache_name@snapshot_name poolname/mock_fs_name
This is lightning quick and requires next to no disk I/O.
If anybody reading this is pondering a weekend project of incredible
usefulness, please consider putting this on your idea stack. ;)
about 64bit things: well, CentOS already got an aarch64 build. I don't
think anyone feels the urge to repeat that effort, just to put another
nametag on it. (same for armv7)
My thoughts exactly. There is enough broken on CentOS 7 where we could
lend a hand for maximum effectiveness (e.g. by providing fixed packages
in our repositories) without repeating the tedium some of them are doing
as part of their day job.
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
