[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jehan Bing
Subject: Re: [Ltib] Fix + Optimization when checking for updated source
Date: Fri, 23 Mar 2012 11:01:36 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0

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)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]