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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/ltib > _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
