HOWTO: Patch & Rebuild a Package
by Jerico James Flores MiloGetting AsteriskNOW to do exactly what you need seems a little tricky at first for developers not familiar with conary.
How do I recompile <somepackage>??
Where's the source code??
AsteriskNOW comes with all the development packages you need in order to get started, like gcc, libstdc++, etc..
But where's the source code?
Short answer, there is none.
This is because using rPath's technology, developers only need a set of instructions for the computer to follow in
order to obtain the right results (binaries in this case).
This is where recipes come in. Recipes tell conary where to get source code, what patches to add, and where to
put it when its all done. Additionally, it can also specify libraries that it provides or requires in order to be built
(this is a dream come true for packagers). I'm sure all the RedHat/Debian users all say 'but [RedHat,Debian] can do that'
Well for anyone thats ever hosed a system by doing an 'apt-get upgrade' or something similar with redhat/yum you
discover there are inherent problems with those package managers. Mainly due to their 'dumb' behavior, as in pull
the latest package for that version of distribution. Well those binaries store limited amounts of history of buildtime
dependencies (normally something libsomething.so.4) and can create problems when something like an api change
made it into a non-major release of a library.
This is where Conary is different. In each package, conary stores build & runtime dependency versions; down
to what version of code, what version of recipe, and what build iteration. Granted it's still linux, but now
with the ability to drill down to exactly where/when that package and its contents came from, as well as
where to go for information on its dependencies.
Now, after all thats out of the way, down to the nitty-gritty...
How do I recompile <somepackage>??
Where's the source code??
AsteriskNOW comes with all the development packages you need in order to get started, like gcc, libstdc++, etc..
But where's the source code?
Short answer, there is none.
This is because using rPath's technology, developers only need a set of instructions for the computer to follow in
order to obtain the right results (binaries in this case).
This is where recipes come in. Recipes tell conary where to get source code, what patches to add, and where to
put it when its all done. Additionally, it can also specify libraries that it provides or requires in order to be built
(this is a dream come true for packagers). I'm sure all the RedHat/Debian users all say 'but [RedHat,Debian] can do that'
Well for anyone thats ever hosed a system by doing an 'apt-get upgrade' or something similar with redhat/yum you
discover there are inherent problems with those package managers. Mainly due to their 'dumb' behavior, as in pull
the latest package for that version of distribution. Well those binaries store limited amounts of history of buildtime
dependencies (normally something libsomething.so.4) and can create problems when something like an api change
made it into a non-major release of a library.
This is where Conary is different. In each package, conary stores build & runtime dependency versions; down
to what version of code, what version of recipe, and what build iteration. Granted it's still linux, but now
with the ability to drill down to exactly where/when that package and its contents came from, as well as
where to go for information on its dependencies.
Now, after all thats out of the way, down to the nitty-gritty...
Making Conary changesets is a little different than making RPMS or debs (although if it makes you feel
any better, some of the original developers of RPM created Conary)
any better, some of the original developers of RPM created Conary)
In this example will do a more complicated example which demonstrates the more advanced features
of conary, just for good measure
Say I want to add a patch to zaptel, (this requires building against kernel headers,
hence more involved
) 1. First, you'll need to checkout the recipe
- CODE: SELECT ALL
cd /home/admin/src
cvc co zaptel
cd zaptel
2. Now, place your patch in the dir, edit the recipe and add a line for your patch somewhere
after the r.addArchive, but before the r.Configure
- CODE: SELECT ALL
r.addPatch('mypatchfile.diff')
NOTE: the patch will need to be generated from the top-level dir of the
zaptel source (this is normally the case though)
3. Now we'll need to cook the recipe, you may need to specify a different kver
and leave off the '[zaptel.smp]' if its non-smp
- CODE: SELECT ALL
cvc cook --macro 'kver 2.6.17.11-1.1.smp.x86.cmov' zaptel.recipe[zaptel.smp]
This is where the 'complication' comes in. Normally you wouldnt need to supply
all of these options, but since we need to build against a kernel we have to tell it exactly
which one, otherwise CRASHBOOMBANG
4a. Now it might barf due to unmet dependencies which you can install with conary
- CODE: SELECT ALL
sudo conary update <package>:<component> --resolve
4b. You may need to get the kernel headers too
- CODE: SELECT ALL
conary update kernel:build-tree --sync-to-parents
If it builds successfully you'll end up with a <package>-<version>.ccs file, which will
be in the directory from where you executed the 'cvc cook ..'
5. Finally. install the .ccs file via conary
- CODE: SELECT ALL
sudo conary update zaptel-1.4.0.ccs
Hope this answers most of your questions and best of luck!
