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

[Stuart Hughes]

On 01/02/11 14:13, Peter Barada wrote:
> 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,

[snip]
> 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.

In this particular case you're right, but this is not clear-cut to me.
I think that fundamentally if you're doing kernel work (or u-boot) then
those packages should be using directory tree builds, which you
externally update (whether using rsync, git, cvs etc).  For the
tarball+patches case it just doesn't work that well, and although you
can come up with a scheme that works in some use-cases, I don't think it
would be robust (or simple to safely implement).

If you change to directory builds, I think the problems/use-cases you
have would be resolved.  Is there any chance you can re-think your
strategy and use directory builds?

> 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?
> 
> 
Around line 815.

Regards, Stuart