Hi,
On Thu, Aug 08, 2013 at 08:34:09PM -0400, Erik Schnetter wrote:
ExternalLibraries thorns containing tarballs can be very large, in particular if the history of the thorn grows and contains multiple tarballs.
It only really grows (for the user) if a revision control system is used that stores all of the history on the client side - something a user wouldn't be interested in usually, for external libraries. git is one of these. A counter example is Subversion, which wouldn't have that problem, and all external libraries are currently stored in Subversion.
Other advantages of storing source trees are:
- this is what we do for every thorn, so why not for ExternalLibraries (d'oh)
External libraries are not like other thorns. Even when present in a thornlist, the source of external libraries might not be used in the end if a system versions is detected and usable, but it needs to be present. Decompressing all external libraries would lead to even more small files, which especially on clusters could get you into trouble. Of course you need to have the inodes when you compile it anyway, but again: you might not need to (compile it), and most of these are deleted again after the build.
- one can easily look at the source code of an external library
- no need to untar and later delete the source tree while building
For a regular user this happens automagically, but I agree that this would be a plus for the maintainer of that thorn.
- no need to apply patches -- the changes can be made directly in the source tree
I don't think this would be good. I would like to see which changes the Cactus thorn did compared to the vanilla version. Also, from a developers standpoint maintaining patches is far easier for upgrading the library than recreating and applying patches every time for an upgrade by hand. I strongly urge everyone to keep the vanilla version clearly separated from Cactus-specific changes.
In my opinion, this is the way to go. I am currently setting up a new repository of ExternalLibraries/Boost in this way. (Obviously, it is not possible to keep the current repository, since its history is already at 406 MB.)
I don't really see a problem with the current setup. Even the boost svn checkout shouldn't be that large. The problem you describe really only applies for a git repository. We don't need to use git. We even don't use git for the external libraries.
Frank