HOWTO: Patch & Rebuild a Package asterisk now

HOWTO: Patch & Rebuild a Package

by Jerico James Flores Milo

Getting 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...

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) 

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!