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

[Peter Barada]

On 02/01/2011 04:16 AM, Stuart Hughes wrote:

On 31/01/11 18:38, Peter Barada wrote:

On 01/31/2011 12:52 PM, Stuart Hughes wrote:

Hi Peter,

I started implementing this and again I found myself asking; what if
someone has edits they want in that directory and they get clobbered?
Whether tarball or svn (git, cvs etc) based packages, no one will thank
you if their precious work gets zapped.

The only safe way to do this would be to ensure prior to source removal
ensure that the sources have not been changed.  The problem with this is
that:

* This can take a long time as it needs a full unpack of the reference
and then a diff -q, which I guess could be okay/acceptable

* This can only work for tarball based package which is okay/acceptable

* This is not reliable unless the clean/distclean for the package
actually works. Which may/may not be acceptable

Let me know if:

a) You agree with my reasoning

b) You still think this is worth trying to do (it's more complicated
than the patch you sent)

I believe its still worth doing for the tarball/patch case to make LTIB more usable in an automated build system as part of continuous integration development where user interaction is impractical.

"--clobber" is not a switch for the feint of heart; it specifically allows LTIB to remove something that could possibly contain changes you want to keep, and should only be specified by those that fully understand the risks of doing so.

W/o digging into RPM deeper, is there any way RPM can determine if a .spec files contains %source/%patch changes (from the databse LTIB keeps) that require re-executing %prep to bring the source into sync?

There's nothing I know of in RPM that can detect changes to
%source/%patches.  The state handling side of things needs to be in LTIB.

Hmm, gotta sit down an really relearn perl to fully understand everything LTIB does.

One suggestions for you.  In the auto-builder I maintain (the one that
post results to this list).  At the weekend when I do a full re-build
from scratch, I do (in an external script) rm -rf rpm/BUILD/*
Maybe that would work for you?

It would if I only built once per weekend from scratch; I'm currently building on any change to LTIB/kernel/u-boot/x-loader SVN trees, and that would overwhelm our buildslave(s).

Also I don't think that would works for anyone who has helloworld_mod enabled and patches helloword_mod w/o patching the kernel.  In that case the kernel .spec file is clean relative to the built kernel rpm so the kernel will not be built (or %prepped).  Then helloworld_mod .spec file is out of date relative to the helloworld_mod RPM and will attempt a %build - w/o the kernel source which fails THis was the same problem I ran into regarding PKG_KERNEL_NEEDSRC(when ltib's use of transient LEAVESRC would cause the next naked "./ltib" to fail since the kernel source was removed) where the only way it worked properly was to remove rpm/BUILD/* and rpm/RPMS/* and effectively rebuild from scratch.

Where in LTIB does it setup the links in rpm/SOURCES for the patches - I could use that to tell if an additional patch to a package has been created?

Regards, Stuart

-- 
Peter Barada
address@hidden