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