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

[Stuart Hughes]

Hi Jehan,

Thanks for your comments and ideas.  I've added -quit to the find
clause, but for now I'm not going to add the -L option for the reasons
cited before.  One example is /etc/mtab, which in some cases is a
symlink to /proc/mounts, which could confuse find.

Regards, Stuart

On 23/03/12 18:01, Jehan Bing wrote:
> On 2012-03-23 02:00, Stuart Hughes wrote:
>> 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.
> 
> And with symlinks, you just delete them before archiving. Not really
> more difficult and that keep the config in Ltib's menu simpler for the
> people who will use the archive.
> 
> 
>> 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.
> 
> Hmm, couldn't that be problem with a directory build pointing outside
> rpm/BUILD too? I mean with the directory build, "rpm/BUILD/package"
> doesn't exist at all so if something doesn't handle the directory build
> correctly, it could still break. At least with symlinks,
> rpm/BUILD/package is still valid.
> 
> 
>> 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.
> 
> I personally thought it was a good side effect. After all, if a package
> depends on something and that something changes, the package should be
> rebuilt. It shouldn't matter where that something is.
> But in other case, it might not be so good either (a symlink to / would
> be awful). So in the end, it really depends on why and where that
> symlink points to. Both option are valid in my opinion.
> 
> That said I believe that following symlinks offers more flexibility. If
> "find" doesn't follow the symlinks, there is little one can do. If
> "find" does follow them when one doesn't want to, the symlinks could be
> created when building the package and deleted just afterwards, or the
> code could be patched to get the files directly to the correct location.
> 
> 
> Anyway, I keep defending the symlinks but I don't really have a strong
> opinion either way.
> I'll keep my version of ltib patched to follow symlinks because it will
> solve our problem with static libs. And having that, it becomes
> pointless to switch to using directory build (at least until we find
> something that does break)
> 
> Cheers,
>     Jehan
> 
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/ltib
>