Wow, quite a few responses. I'll try to sum up my response. Regarding arm64, I was not aware that CentOS/RHEL had arm64. In that case, I may try them out for my 64 bit Pi sometime.
Regarding mock, I did not realize that about rpms getting different results based on extra packages. My attempts at building the whole repo were merely an exercise designed at getting the missing packages, so that if I were to build updates to existing packages, I'd already have the deps installed. But at your advice, I will scrap what I have, and try mock/koji. With mock/koji, do I still need to install packages like I did, or does it require a different method to get those packages? Also, given that I've got some similar concerns about SD wear, I was considering mounting a share from my main server to do the actual builds in. Would that be workable in a chroot env that is getting destroyed and rebuilt all the time? On Apr 9, 2016 07:45, "Gordan Bobic" <[email protected]> wrote: On 09/04/16 12:07, Bjarne Saltbæk wrote: > > > > > 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. > or from at Makefile in a SCM (git, svn or git) just to clarify :) :) > > 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. > Yea and no. No In that sense that it will just build a package as > mock/rpmbuild. > Yes in that sense that it has a feature - "chainbuild". I have not tried > it yet. but as I read it, you can define a build task as a chain of > builds. In this way you can build dependencies for a package before you > (in the end of the chain) build the package. Very neat for build > bootstrapping an OS. > I don't think it works out the dependency chains itself, though. > 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). > Agreed. Let the CentOS guys maintain the 64-bit arm RHEL-based OS and > RSEL focus on 32-bit arm OS. I assume there will still be a need for 32 > bit arm support for a long time. > Yes and no. There is an armv7hl build of CentOS 7. It is running my plex server in a docker container on an CentOS 7 aarch64, so I know it works OK for server tasks at least. The main use cases for RSEL are: 1) If you want to use EL6 on ARM, we are the only option (for all those who detest systemd enough to not upgrade for as long as possible). 2) If you are on pre-ARMv7 hardware, we are the only option for EL6 or EL7. That means all the *Plug hardware (ARMv5), R-Pi 1 (ARMv6), and various NAS-es, e.g. QNAP TS-421 which was until recently my main internet facing server. 3) If you don't feel armv7hl build of CentOS 7 is quite there yet (there are packages missing, and thanks to Jacco we have the only working EL 7.2 where gnome isn't broken. Having said that, I expect the CentOS guys to absorb those changes soon. My main annoyance about soft-float ARM at the moment is closed source video drivers. For example, ARM only provide hard-float Linux Mali drivers (but they provide soft-float Android drivers). And in that boat, Nvidia only provide 32-bit hard-float drivers (but not 32-bit soft-float nor 64-bit ones, and my thread on the Nvidia developer forum requesting 64-bit drviers got deleted). But that's a whole different thread. Gordan _______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
