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

[Peter Barada]

On 01/31/2011 11:21 AM, Stuart Hughes wrote:
> Hi Peter,
>
> Okay, I think I understand the requirement now.  I won't rely on the svn
> tag in the name, I think that's too weak/restrictive (in case someone
> wants to use git or something else).  Instead I think the absence of a
> SOURCE: tag should be the clue to LTIB that this is a directory build
> (svn, cvs, git etc) and so clobbering is not allowed.
>
> Would you like me to send the patch to the list for you to look at/try
> out before checking in?
Sure, I'll give it a whirl...
> Regards, Stuart
>
> On 31/01/11 15:22, Peter Barada wrote:
>> On 01/31/2011 10:10 AM, Stuart Hughes wrote:
>>> Hi Peter,
>>>
>>> Okay, there are 2 separate use cases here;
>>>
>>> 1/ The tarball+patches builds
>>>
>>> 2/ The SVN (SCM) based directory builds.
>>>
>>> In the case of 2/ all that I've said before stands (e.g. clobber is a
>>> very bad idea).
>>>
>>> In the case of 1/ your patch would be reasonable, but I would also add a
>>> prompt to the user to make sure.  This would be bypassed if the --batch
>>> option was in force (e.g. for auto-builder).  My preference would be to
>>> limit this to only tarball based builds.  The detection I'd propose is
>>> checking for the existence of a source tag being present.  Does this
>>> sounds reasonable?
>> That sounds perfectly reasonable.
>>
>> However in the case of #2, --clobber can't happen for a SCM build since
>> in this case the patch has:
>>
>>     # If its a SCM (source code management) package, force prep
>>     my $svn_bld = 0;
>>     if ($tok->{version} eq 'svn') {
>>     $svn_bld = 1;
>>     *$dir_bld = 0*;
>>     }
>>
>> And later:
>>  
>>        if ($cf->{clobber} && *$dir_bld* && $unpack eq 'yes' && $spec_upd) {
>>         print "Clobber forces removal of
>> $cf->{rpmdir}/BUILD/$tok->{pkg_dir_name}\n";
>>         system_nb("rm -rf $cf->{rpmdir}/BUILD/$tok->{pkg_dir_name}");
>>         # force prep
>>         $dir_bld = 0;
>>         }
>>
>>
>>> Regards, Stuart
>>>
>>> On 31/01/11 14:23, Peter Barada wrote:
>>>> 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
>>


-- 
Peter Barada
address@hidden