> > First thing I finally discover is the file compression > is tar.gz and not > > tar.bz2. When did that change? > > It didn't; they were always tar.gz when I created > them. bzip would take > overnight to run; as it is gzip takes many hours. To > me, the difference > in compressed file size was not great enough to justify the > performance > hit from bzip. My scripts were written for tar.bz2 and use wget to fetch tarballs if none are found locally. The other day I downloaded files. The script would have failed if the files were tar.gz. Something strange here. > > Second, the non-core packages all have "3.5.12" in the > source tarball file > > name. Previously those packages used a local version. > > > > arts: 1.5.10 > > koffice: 1.6.3 > > k3b: 1.0.5 > > etc. > > > > Now all of them are 3.5.12. > > That is normal and will stay that way for all future > releases, unless > there is a good reason for not doing things this way. Then I have to rewrite my scripts. This problem never arose while building from SVN. Thus, I never anticipated that change and is an example of why we need time to test downloading and building tarballs. > > Third, when the non-core tarballs unpack, they are in > a subdirectory > > rather than just under the package name. For example, > both tqtinterface > > and arts unpack to a parent directory named > dependencies. Koffice, knemo, > > k3b, etc all unpack to a parent directory named > applications. Yes, that > > matches SVN, but the tarballs don't need to match SVN. > Downstream builders > > will not be expecting that. They will expect the > unpacked tarball to be in > > its own directory of the same name. > > This issue I can definitely fix. Thanks. I can't blink my eyes and this stuff magically compiles. :) Compiling is an overnight process for me --- and that is if nothing breaks. I have yet to read about any physicist who has a working theory for bypassing time. :) As we have seen many times, your process does not break because you remain with the Debian build process and inherited sources from Debian. Also, you have your way of doing things ("works for me!") and that works well for you, but needs to be tested if others are going to help support Trinity on non-Debian systems. Breakage takes time to fix with the other operating systems. I presume you want to keep the October 1 release date, but I can't commit to any Ubuntu like schedule of "release --- ready or not". I prefer a "release when ready" schedule. I doubt waiting a few days is going to hurt anybody?