> I added check if submodules were initialized. Second script can be useful for
> create tarballs for all modules. Please, look at this.

I say just go ahead and add the scripts to the source tree because nobody is forced to use the scripts. Those who choose to use the scripts will let us know about bugs and improvements.

My guess is most people who build from GIT are not interested in creating tarballs because they use a local repository. On the other hand, we have a distinct need to create tarballs with each official release. As we now support point releases, that means a tarball set for the upcoming 3.5.13.2. Likewise for R14.0.0, R14.0.1, R14.1.0, etc. Therefore these scripts could serve us well in automating the creation of those tarballs.

A concern I have with official tarballs is permissions --- addressed in bug report 350. The 3.5.13.1 tarballs had this problem. :) Running the tarball scripts as root will automatically create proper ownership of root:root, but we still need to ensure all files are world-readable.

> The question is whether adding label 'trinity' for packages that already
> contain 'tqt' in the name? For example: avahi-tqt, dbus-tqt,...

I noticed that question yesterday with my own packages. After updating my build environment several days ago to support the text string "trinity" in the package name, I now have packages like trinity-python-trinity. If I used the text string "trinity" as a suffix to the base name, the package would be python-trinity-trinity. The latter method looks goofy, the first method only a tad goofy.

Yet I'm going to leave things as is. That will mean I'll have a few packages with peculiar names such as trinity-python-trinity, but want that anyway as a way to distinguish all of my packages as belonging to the Trinity project. If I used only python-trinity then some people might think I am providing a specially modified python package for Trinity. That would be goofy too. :)

Darrell