On Tue, Jun 14, 2016 at 06:22:05PM +0200, Lenz Emilitri wrote: > 2016-06-14 17:44 GMT+02:00 Tzafrir Cohen <tzafrir.co...@xorcom.com>: > > > > 1. Asterisk basically has such a script inside. > > It is - as you say - inside. This is outside and does the download for you. > > > 2. Asterisk has an RPM package. An RPM package is exactly a reproducible > > build (listing dependecies, and such). > > It's true. They are very interesting, especially if you are a > historian of software. > http://packages.asterisk.org/centos/ > > If you need something less, say, "vintage", you may need to compile it > yourself. > > > 3. You are reinventing RPM. Badly. Do you people really want to run: > > - As root > > - A huge blob nobody can inspect > > - that is executable, and hence has tons of places to add nice hooks > > in? > > > > Learn how to use rpmbuild. > > I personally happen to have shipped RPMs for about 10 years now. But > building a RPM might be overkill if you are deploying a test, > throwaway box, or just once for a Docker image. Of course I would not > use this as an RPM substitute, and if I were to use something like > this I'd fork it or at least read it (it is maybe 20 lines). YMMV. > > And IIRC there is more places to ship "nice hooks" into a binary you > ship as an RPM than in a shell script that does what you would > manually from the terminal!
RPM is one of the common formats to describe building of a package. There are other such similar formats, but if you're on Centos, RPM is already included with the platform, and hence it makes sense to use it. An RPM package is an archive (technically: cpio. But you don't get direct access to that) with a small dictionary attached in front of it. That dictionary specifies the name, version, revision, and many other fields. There are basically two types of RPM packages: source and binary. Binary ones ar ethe products of builds. Source ones describe how to build, and thus they are the ones that interest us. A source RPM package has in its archive a spec file, sources (one or more) and patches (zero or more). The spec includes instructions how to build a binary package. So if you don't have any patches, the one thing you need to maintain is ths spec file. Everything else (including the source tarball) could be automated using the standard RPM build toolchain. It would also be nice if you could verify the signature on the tarball[0]. I personally prefer git-buildpackage-rpm that allows keeping the "tarballs" in git. You can either use tags directly to get tarballs from, or use pristine tar to store the delta between a tarball and a tag. But right now this is not a standard tool on Centos systems, and you'll have to install it on your own[1]. The standard RPM+Git toolchain in Fedora seems to be fedpkg[2], but I think it would take quite some tweaking to make it work with your own seperate tarball repository. I don't think it is useful for your case, but maybe someone more familiar than me can give an answer. If you really want to avoid conaminating the build system with all of those packages, do a chroot build inside mock (supported by the above two, or directly). A bit slower, and a longer debugging cycle, but keeps your system clean. It has support for caching downloaded packages and such. So in short, one proposed method: 1. Install git-buildpackage-rpm 2. Clone the package asterisk 3. Create a branch called, say, packaging, with: rpm/asterisk.spec debian/gbp.conf # Why Debian. that's the way it is cat <<EOF >debian/gbp.conf [DEFAULT] packaging-branch = packaging upstream-branch = master upstream-tag = '%(version)s' packaging-dir = rpm EOF 4. Run: gbp buildpackage-rpm -ba # or also: --git-mock --git-dist=epel-7 If you use mock, mock pulls all build-dependencies on its own. If you don't, then you should probably use yum-builddep (from package eyum-utils. But I never tried it). Oh, and what if you just want rpm for getting the build dependencies installed and for running ./configure, 'make' (and menuselect) with the right magical arguments, and then you'll run 'make install' on your own? Use -bc instead of -ba / -bb. You'll end up with a built source tree. su[do] make install, and you're done. [0] On Debian uscan only aquired this ability relatively recently. When I wrote a similar script a decade ago[4] I just verified the md5 checksum to verify that I can safely avoid re-downloading. [1] RPM support is already mostly merged to the main git-buildpackage project: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ . Some extra features may be available in https://github.com/marquiz/git-buildpackage-rpm [2] See https://fedoraproject.org/wiki/Package_maintenance_guide?rd=Using_Fedora_GIT [4] http://updates.xorcom.com/astribank/bristuff/1.4/INSTALL.html -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
