Re: [Ltib] Fix + Optimization when checking for updated source

[Stuart Hughes]

Hi Jehan,

That gives me a better idea of what you're trying.  IMHO I think despite 
the extra effort, you'd be better off using the directory build method, 
as that will allow you to do whatever in your SCM controlled area and 
have it still play nicely with LTIB.

Also the idea of directory builds is that when you've finished 
development and make a release, you select the normal (non dir-build) 
.spec file and that works from an archive (tarball) of a release.

My biggest concern about using symlinks is that the expectation (other 
than directory builds) is that the area being worked on is sandboxed to 
rpm/BUILD/package, and so the control logic may not work if that 
assumption no longer holds.

One final note, following symlinks in the find may cause some 
side-effects as it's possible/likely for a package to have symlinks to 
system areas which should not be followed.

Regards, Stuart

On 22/03/12 18:06, Jehan Bing wrote:
> Indeed we could use the builddir/buildsubdir variables, that just 
> slipped my mind.
>
> We used to have the packages directly in rpm/BUILD but we recently 
> refactored our scm with one empty super-project and lots of 
> sub-projects (package1, package2, ltib) at the root of the 
> super-project. And the straightforward, minimal fix was to just 
> symlink the new location to the old one.
>
> Symlinks seems slightly cleaner though because then the spec file 
> doesn't depend on our scm setup.
> Hmmm, maybe I'll add a "SCM_ROOT_DIR" var as a ltib config, that's 
> probably even better.
>
> That said, symlinks worked fine so far with the exception of detecting 
> the updated source. Maybe it causes issues on some cases but we 
> haven't hit any so far.
>
>
> Another thing we are thinking of using symlinks for is to force a 
> package rebuild when a static library is rebuilt.
> Right now, if package1 builds a static library and package2 depends 
> it, when package1 is updated, package2 is not. If "find" follows 
> symlinks, we could just symlink the static lib in the package2 
> directory and that would trigger the rebuild.
> Maybe you have a better solution to that problem?
>
>
>     Jehan
>
> On 2012-03-22 02:21, Stuart Hughes wrote:
> > Hi Jehan,
> >
> > I think the -quit is definitely something to add.
> >
> > As far as the other stuff goes, I see what you're trying to do, but I
> > wonder what your scenario is?
> > With the exception of the kernel, I would not expect symlinks in
> > rpm/BUILD. If you want to have packages outside the build area, the
> > normal mechanism is to use the 'directory build' method, this allows you
> > to independently manage the source tree (e.g. svn, git, cvs). For an
> > example see:
> > dist/lfs-5.1/dtc/dtc-dir-build.spec.in
> > config/userspace/dtc.lkc
> >
> > The concern I have with this approach for normal packages is that not
> > all operations will work correctly. It's been a while since I've looked
> > at this in-depth, so I can't recall all the issues.
> >
> > I'm not saying no to this, but I'd like to understand a little more
> > about what you're trying to achieve by having symlinked packages.
> >
> > Regards, Stuart
> >
> > On 22/03/12 01:09, Jehan Bing wrote:
> > > Hi
> > >
> > >
> > > Our ltib setup is currently this:
> > > package1/
> > > package2/
> > > ltib/
> > > rpm/
> > > BUILD/
> > > package1 -> ../../../package1
> > > package2 -> ../../../package2
> > >
> > > because rpm/BUILD/packageX is a symbolic link, "find" returns
> > > immediately when checking if the source was changed and doesn't
> > > actually check the source. One option is to add a / at the end of the
> > > directory name ("find $src_dir/ ..."). But there could also be
> > > symlinks inside the directory pointing outside tree so I think use
> > > "-L" to follow _all_ symlinks is a better idea (though it can slow
> > > down the check quite a bit if the symlink points to a big directory)
> > >
> > > Also, find will search for _all_ the files that are newer than the rpm
> > > but knowing that one file at least changed is enough and checking the
> > > rest is just useless processing. So find should use the "-quit"
> > > parameter to stop the search as soon as one file is found.
> > >
> > > Patch attached.
> > >
> > > Cheers,
> > > Jehan
> > >
> > >
> > > diff --git a/ltib b/ltib
> > > index 10134a7..9f66282 100755
> > > --- a/ltib
> > > +++ b/ltib
> > > @@ -904,7 +904,7 @@ TXT
> > > die("'$src_dir' doesn't exist\n") unless -e $src_dir;
> > > }
> > > # See if the source tree has been touched
> > > - $cmd = "find $src_dir -newer $rpms[0] -print";
> > > + $cmd = "find -L $src_dir -newer $rpms[0] -print -quit";
> > > print "checking if sources have been updated: ";
> > > if(`$cmd`) {
> > > print "yes\n";
> > >
> > >
> > >
> > > _______________________________________________
> > > LTIB home page: http://ltib.org
> > >
> > > Ltib mailing list
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/ltib
>
>
>
> _______________________________________________
> LTIB home page: http://ltib.org
>
> Ltib mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/ltib