Re: [trinity-devel] Re: Mirrors and PSB

On Sunday 29 of July 2018 12:15:07 Mike Bird wrote: Hi Mike, you mention "Indeed Trinity successfully used a single repo incorporating trinity-nightly-builds for many years." But here is one basic mistake. The repository trinity-nightly-builds is one of the separate repositories on QuickBuild. At the time of publishing the new release, the contents of this repository is on QuickBuild copied into the official repository. And this is the moment when synchronization of complete content to the mirror begins. There is no "It reduces the number of downloads and upgrades needed for new minor releases and generally provides a smoother and more efficient transition from testing to release." It just does not work in that way. To make the situation even more complicated, you know that I also have the repositories for preliminary stable packages that are on QuickBuild. However, these repositories is not normally used by any user just for reasons that were with the 'axis' repository. These repositories on QuickBuild I mainly use to prepare packages that will then be published to the official repositories as a new release. Into these repositories, I'm uploading identical source packages as I uploaded into Preliminary Stable Builds repository. But on QuickBuild packages must be built again because into QuickBuild is not possible to upload binary packages, only source packages. It is just these repositories that contain the final packages for new TDE release before they are published into the official repository. And just these packages are downloaded into the cache on the redirector already during the build == while the bandwidth to the primary server is not loaded! And that is the main trick why this cache is so important when releasing a new version. While to the primary mirror synchronization starts at the moment of publishing packages, these packages are already available on the redirector's cache before that time. Simple and very effective. Since this synchronization of packages from the primary server to the redirector cache is for deb packages, the advantate is to use apt-mirror for this purpose. Apt-mirror works in a way that repositories remain consistent during the update. This is why I use apt-mirror for DEB packages, while for rpm packages I use rsync. Here is a small example of the trick. The current stable version is R14.0.4. Therefore, listing the tdelibs folder from apt repository displays packages for R14.0.4: http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/poo l/main/t/tdelibs-trinity/ For example DSC file for Debian 8 (Jessie) is as follows: http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/poo l/main/t/tdelibs-trinity/tdelibs-trinity_14.0.4-0debian8.0.0+0.dsc Since the builds of R14.0.5 final packages are currently underway and these are continuously synchronized to the cache on the redirector, it is now already possible to get files for the future R14.0.5 version. For example DSC file for Debian 8 (Jessie) is as follows: http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/poo l/main/t/tdelibs-trinity/tdelibs-trinity_14.0.5-0debian8.0.0+0.dsc Once the packages will be published to the official repository, the folder listing starts showing new files, the meta-information repositories will refer to new files, and these files will be ready in the cache on the redirector. Simply because they are there in advance. Is it now clear what I mean? Is it now clear why the cache on the redirector is very useful? And it is clear that keeping Preliminary Stable Builds independent of QuickBuild is no duplication because the same duplication is also going on at QuickBuild? Cheers