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

[Peter Barada]

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