Re: [Ltib] Need to remove package build source if that package .spec changed

[Peter Barada]

On 01/31/2011 05:13 AM, Stuart Hughes wrote:
> Hi Peter,
>
> I'm reluctant to add this as it breaks a golden rule that LTIB promises
> not to delete source code once unpacked.  What if some developer had put
> in some edits and forgotten and had the --clobber in a script?
Then they shoot themselves in the foot.  You can't make things completely 
foolproof as God will come along and create a more determined fool...

Perhaps renaming the option to "---clobber" or "--KlObBeR" or even 
"--Remove-prepped-source-if-spec-file-updates" to make it stand out even more 
would help...
> Reading this, and your other email about SVN support, maybe there's
> another way.  Rather than removing the source, why not try to update it;
> this would prevent accidental clobbering and also allow updates.  This
> way different developers can pull in unrelated updates and stay in sync.
That is in the case where a packages is not kept as a tarball+patches but 
instead as a directory under some SCM.  In the case where developer A checks in 
a patch (and correspodning .spec file change to add the %patch), and devloper B 
updates his LTIB source, everything works fine unless the patch checked in is 
an update to a package that LTIB leaves checked out due to another package 
needing the source.

As an example if the LTIB project developer A and B are working on has 
helloworld_mod enabled, then the kernel source will always be left prepped.  If 
Developer A adds a patch to the kernel (and updates the kernel .spec file), and 
developer B then updates his LTIB with the changes from developer A and builds, 
he will not build the change developer A checked in since the kernel source is 
already %prepped.   This can lead to confusion...

> This can be done using this directory build mechanism.  Below is an
> example of what I mean, stripped back as a guide. There are related
> examples in dtc-dir-build.spec.in,
> dist/lfs-5.1/kernel/kernel26-dir-build.spec.in &
> dist/lfs-5.1/u-boot/u-boot-dir-build.spec.in ):
>
> Maybe this could do what you need?
>
> Regards, Stuart
>
> --- a spec file that manages it's own SCM commands ---
>
> %define pfx /opt/freescale/rootfs/%{_target_cpu}
> %define buildsubdir %{name}-%{version}
> ....
> Name            : some_name
> Version         : 1.1
> Release         : 1
> ....
> %Prep
> # only do the code checkout if the target directory doesn't exist
> if [ -e "%{buildsubdir}" ]
> then
>     exit 0
> fi
> mkdir %{buildsubdir}
> cd %{buildsubdir}
> git-clone git://some_url/some_project
> git checkout some_branch
>
> %build
> cd some_project
> git pull
> make
>
>
>
>
>
>
>
>
> On 28/01/11 16:09, Peter Barada wrote:
>> Stuart,
>>
>> As discussed previously, if I have a build that leaves source
>> unpacked
> (because its used by another package as in the kernel source used by
> helloworld_mod), I ran into the problem that if I updated my LTIB tree
> from SVN (and another developer added a patch to the kernel), the
> current version of LTIB wouldn't clobber the kernel source from
> rpm/BUILD. This can lead to serious confusion as Developer A says "Hey,
> I checked in a patch to fix that bug in package X" and developer B pulls
> updates LTIB, does "./ltib" and responds "no you didn't"....
>> The attached patch adds "--clobber" which removes a packages source
> and then runs the %prep step if it detects that the spec file has been
> updated.
>


-- 
Peter Barada
address@hidden