Re: [Ltib] Adding building of kernel from SVN

[Bruce]

I use my own kernel spec to point to the SVN URL I want to build (Like what Stuart described). It's either a tag for the "official" build or it points to the trunk. Actually I cheat and do 'svn switch' in the rpm/BUILD dir when I want the trunk:) Pulling the 2.6.33 source from svn takes a long time.

It works pretty good because when I do a local tag of LTIB, it also captures the kernel URL in the spec file for reproduction.
I do that with other packages as well. Just need to be sure to keep the versions lined up between the spec file an config file.

Thanks,
Bruce

On Mon, Jan 31, 2011 at 8:24 AM, Stuart Hughes <address@hidden> wrote:

On 31/01/11 15:38, Peter Barada wrote:
> On 01/31/2011 04:42 AM, Stuart Hughes wrote:
>> Hi Peter,
>>
>> I can certainly see why this could be convenient for you, however
>> unfortunately I can't merge this.  I went down this patch a couple of
>> years ago with git and in the end you end up with these issues:
>>
>>   * LTIB has to understand the SCP and becomes a front end for the tool
>>   * The floodgate open for SCM system x, y,x (mecurial, cvs, git ......)
>>
>> After a lot of thought I concluded that the best approach was for LTIB
>> to be ignorant and agnostic of the underlying SCM being used for
>> development.  The idea is that for this activity you should use
>> directory build mechanism and handle any SCM work in the .spec file you
>> are using.  This turns out to work quite well, you can put all the SCM
>> handling in the %prep (checkout) and %build (update) sections (I have
>> some examples for git somewhere.
>
> The reason I used %prep to do both the checkout/update instead of splitting checkout/build across %prep/%build is that in normal development you need to %build your changes to test them and only after it works correctly would you check them back into the SCM for others to get.  If you have %build do an SCM update, then while you're trying to test your changes you'll pull in any changes other developers have made that can conflict with your changes...
>
> I admit my approach is blunt and solves my problem.  If I finessed things to hide all the SCM handling inside of a shell script invoked from the %prep/%build section ("scm-prep" and "scm-build" perhaps?)  would that be more acceptable?  Then the decision where the update is doe (either in %prep or %build) can be handled in one spot for all packages using an SCM build...
>

Fundamentally, LTIB cannot be aware of SCM systems, it's a can of worms
(there's too many potentially in used to handle).  So the only thing on
offer is directory builds.  Whatever you implement within a non-shared
.spec file is fine though.

Regards, Stuart

>> Regards, Stuart
>>
>> On 28/01/11 16:32, Peter Barada wrote:
>>> Stuart,
>>> My company uses SVN as its SCM, and I've added support to build a kernel using SVN instead of the tarball/patches to make it much easier for more than one developer to hack up kernel code.
>>>
>>> To support this (and make it properly work with Buildbot) I've modified the ltib script to:
>>>
>>> 1) Ignore .svn files
>>> 2) If the package version is "svn" then we force a build (but not a $dir_bld) to have ltib go throught he package %prep step
>>> 3) Export KERNEL_RESPOITORY (the SVN URL to access the kernel source)
>>> 4) Export KERNEL_SCM_SKIP_UPDATE (to allow skipping "svn update" for a previously unpacked package)
>>>
>>> Note that ltib-svn-kernel-build.patch works in conjunction with my previous ltib-clobber.patch as it uses $svn_bld to set $r (which causes a build) instead of $dir_bld which prevents --clobber from affecting the unpacked source.
>>>
>>> I've also attached:
>>> 1) kernel26-svn-build.spec.in which will checkout/update kernel source (in rpm/BUILD/kernel-svn) from an SVN repository.
>>> 2) kernel_dir_build.lkc.patch which adds KERNEL_REPOSITORY/KERNEL_SCM_SKIP_UPDATE if KERNEL_SVN_BUILD is enabled (assumed this is done in a platform main.lkc where once can select KERNEL_DIR_BUILD)
>>> 3) kernel-common.tmpl.patch to use tar to copy over the kernel header files (as cp fails with "permission denied" on .svn files in the headers)
>>>
>>> I'm sure with a minor additions this approach can be extended to support CVS and git to allow kernel building from any of the common SCMs.  Ultimately it would be nice to extend this to support building any package from an SCM...
>>>
>>> Hope others finds this useful!
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LTIB home page: http://ltib.org
>>>
>>> Ltib mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/ltib
>
>

_______________________________________________
LTIB home page: http://ltib.org

Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib