On 09/04/16 07:40, Mark Campbell wrote:
So I'm a few days behind on reading my email, so I only just now saw
these replies. However, I did some research, and I started with a Centos
wiki page that told me to use rpmbuild to rebuild Source RPMs. I started
out using this method since it was the only one I knew.
That is OK for the odd package, but you really, really shouldn't do it
for large repositories. The reason is that having extra packages that
aren't dependencies can in some cases break the package, either causing
it to fail to build, or produce a broken binary. A typical reason for
this is that the package's ./configure script will look for various
header files. If it finds them it will use them. But if those header
files shouldn't be there because they break the build, it will cause
problems. I have seen this happen a number of times. Another similar
side-effect can be that the package ends up getting linked against
libraries that aren't in it's foreseen dependency list, and then
subsequently fail to install run once it is installed.
Does mock / Koji use rpmbuild as its base?
Koju uses mock to create a minimal dependency chroot. Inside that
minimal dependency chroot, it uses rpmbuild to rebuild the src.rpm.
I wrote a simple script that did a for loop of
all of the source RPMs (synced them all from mirror service 's copy of
epel), and ran them through rpmbuild. Started off with a buttload of
errors in the form of non installed dependencies. Just today, I told my
Raspberry Pi 3 to install something like 9 gigs worth (expanded) of
packages (my script parsed the output of all of the failed builds for
the packages they needed, and piped them into yum install). I had to
leave for work (well) before it finished so I'm not sure how far it's
gotten. Is mock / Koji easier on these dependencies in the OS?
Mock will install the @buildsys-build set of packages that are the basic
set of dependencies for building packages, on top of the minimal root.
On top of that dependencies for the package itself are installed.
However, if you are asking if koji is more clever about the build order
in the sense that it will figure out the dependency tree and build the
dependees before dependers, no, it won't.
I will say this for the Raspberry Pi 3, though, it seems to be
comparatively powerful for building. While I did have a lot of failed
packages I must have gotten a good 500-1000 or so (epel totals ~10000)
built in just several hours.
I typically order my builds in ascending order of src.rpm size. While
the code size isn't a direct indication of the build time, it's a pretty
good first pass approximation.
As for build times, getting the first pass build of EL6 through took
months of CPU time on {Sheeva|Guru|Dream}Plugs.
That also reminds me. Are there any plans for 64 bit builds of
redsleeve in the future? I didn't care that much before, but now the Pi
3 is a 64 bit process, and I'm curious if it would have any better
performance in 64 bit vs 32 bit.
While I am open to requests (and volunteers :) from the community for
such a task, the reality is that CentOS guys do have an aarch64 build of
CentOS 7, and it works quite well (I run it on my MP30-AR0. There are
some thing that are IMO broken/pointless/daft. Not in their opinion,
though, since they are for the large part blindly following PNAELV's
decisions. The example that comes to mind is their kernel choice and
onfiguration - specifically, they ship with a kernel that uses 64KB
memory pages, rather than 4KB. This not only needlessly wastes memory
bandwidth (I pasted a link to some choice quotes from Linus on the
subject on the CentOS mailing list recently on the MP30-AR0 thread), but
it also brakes binary compatibility for running 32-bit ARM binaries in a
chroot (e.g. for running CentOS 7 armv7hl or running RedSleeve armv5tel
in a docker container, or running mock builds for them). They also run a
slightly patched 4.2.0 kernel which is ancient, unmaintained, and
EOL-ed. Consequently I have a LT 4.4.6 kernel and intend to maintain the
RPMs for it myself.
The point I am getting to is this:
1) I don't think there is any benefit in duplicating their work now that
they have finally caught up with us after 5 years. That just seems like
a huge waste of time where it isn't necessary, and they are at least
better funded (IIRC some of their maintainers are on the PNAELV payroll,
and get paid for it, rather than doing it only in their spare time like
we do here).
2) I believe there _IS_ scope for maintaining our own aarch64
repositories containing the packages we deem broken in CentOS, or those
that CentOS don't ship at all. Examples include:
2.1) Kernel, based on LT kernel release(s), as discussed above.
2.2) Various packages that they don't ship and don't intend to ship, or
that aren't being kept immediately up to date in other repositories like
EPEL. Off the top of my head xamples of what I use myself that falls
into this category include:
- ZFS
- mod_security
- mailman (until/unless we switch to google groups, which we probably
could/should)
- WordPress
We could also include fixes that CentOS guys haven't gotten around to
yet, e.g. the recent gnome fix that Jacco put together recently.
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
