![]() Once upon a time Solus employed the legacy actions.py / pspec.xml format inherited from PiSi. As an added layer, developers are free to utilise the local repository functionality of solbuild to build massive local changes/additions before staging them for inclusion in unstable. As such we’re able to make sweeping architectural changes, or even perform large stack updates such as the recent updates to MATE 1.20 or Plasma 5.12. This affords the user a safety blanket, and developers have more freedom to make the necessary changes. Our processes are such that every weekly sync constitutes a new release of Solus Shannon, whilst unstable continuously rolls. If we truthfully evaluate the branches here, then unstable is technically the “real” distribution, and Shannon is a rolling, tested snapshot of unstable. All of this comes for “free” with our architecture, allowing us to maintain a high velocity without making any sacrifices. Doing so allows us to retain multiple backversions of packages and extended graphs for delta packages, reducing the size of the update download for users. Behind the scenes we’re using various deduplication techniques, including reference counting of all asset IDs in the pool, and hardlinking these packages between unstable and shannon via the pool to minimise the total disk usage of the repository. This makes the sync process incredibly fast, and we can immediately begin hacking on unstable again.Īdditionally, ferryd will spawn delta operations to produce any missing delta packages for Shannon in the background, which will turn up post-sync to minimise bandwidth consumption for users on Shannon. Typically this operation takes 15-20s and pulls all new/missing packages from the current versions published in unstable, into shannon. ![]() When all is well, we’ll perform the weekly (typically Friday) sync into stable. At this point, we perform any remaining testing with real hardware, and produce test ISOs to verify our changes. Every week, we go through this iterative development process and re-stabilise the repository in time for a weekly sync. Thus, developers will opt for unstable to allow time to stabilise this update window, whilst the vast majority of daily users will be on the stable channel (known as Shannon). ![]() The unstable repository does have a tendency to live up to its name, however! In a single week we see hundreds of changes, and many breaking changes and fixes. This allows us to maintain a high cadence as well as provide convenience for the bandwidth-constricted. At the same time, ferryd will schedule delta updates in the background so that the update cost will be minimised for future users, whilst also keeping the main processing queue unblocked. These packages are checked against the transit manifest to verify the payload, and upon success they’ll be generally available in our repository. Within 15 seconds of a set of packages reaching ferryd, they will be included in the unstable repository. A remote build server will clone the same repository from an immutable git tag, and if the build succeeds, it will be uploaded to our ferryd instance for further processing. Once a developer is happy with the changes, the release number is bumped, and they run make publish to schedule a build on our build controller. To The RepositoryĪny package in Solus starts life in a git repository hosted at the dev portal. Lastly, we’re not claiming to be perfect! There are other areas to attack, and we continue to evolve, and hope that our approach in tackling these issues may be useful to projects outside of Solus, be it code or just philosophy. This article will help you understand exactly how we got to this point, and highlights the invisible parts that make Solus what it is. In fact, Solus 1.0 was intended to be a statically versioned, classic distribution, which has since significantly evolved over time into a fully fledged rolling distribution. ![]() Importantly, one should remember that Solus 1 looked absolutely nothing like what we describe below. On the surface this may sound trivial, but how do we sustain that over time? In a nut shell, our tools and processes are extensions of our philosophy, and enable us to continously deliver. One of the driving aims of Solus is to provide a stable rolling release Linux distribution with a focus on the desktop. Do note this is a technical article, and doesn’t encompass every area of Solus for the sake of brevity. In this post we’ll be exploring the Solus architecture, going over some of the key differences separating it from other projects. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |