Feature #8256


Source code availability per every landing, using ZFS snapshots of source-archives

Added by Nikola M. over 6 years ago. Updated over 6 years ago.

Release Engineering
Target version:
Start date:
Due date:
% Done:


Estimated time:


Current state:
Alternative location (mirror) for downloading upstream source code archived tarball for oi-userland is: ( which can be used automatically if you set the EXTERNAL_ARCHIVE_MIRROR variable.)

The feature request:
Proposes for Openindiana to have source code availability , that are accesible per-every landing and refresh in public repositories.

Zfs dataset(s) holding oi-userland/source-archives/ can be zfs snapshot -ed on every osnet-incorporation and userland-incorporation update,
so that the source code for every landing in /hipster repository from Jenkins, also have same-named snapshot, that is also available from the outside world.
For example:
If there is ,5.11-2017.0.0.8925:20170519T221014Z , to have all upstream source code available for that state of packages, there only needs to be the zfs snapshot:,5.11-2017.0.0.8925:20170519T221014Z ,
that is made available under:

Additional repositories to snapshot on build:
That could also work for osnet-incorporation , where osnet-incorporation specific sources and other packages that build with osnet-incorporation could be on oi-osnet/source-archives/
and for hipster-encumber repository in oi-encumbered/source-archives/

Zfs snapshots of previously used source states for building packages during binary repository update process between snapshots,
could be destroyed, after in-between binary builds have been made unavailable/deleted.
Also some of the snapshots can be later cloned, to form source base for future supported branch, also without using additional space.

Deletion of sources zfs snapshots , between 2 OI snapshot source states, go to be careful, not to destroy also snapshots for sources for OI snapshots, because OI snapshot ISOs and .usb images are going to be available for a long time, so source code should be also available.

Rationale and benefits:
All this is done because binary distribution gives burden to those distributing built binaries, to also distribute the source code at all times and at the same time with the binaries distribution, to satisfy colypeft licenses used by most of the packages.

This snapshot-and-make-available step, as the part of Jenkins automated publishing, is painless, can be set to be automatic, be low resources and is relatively easy to implement to solve the burning problem with mandatory source availability of binary-distributed copyleft source components, per their respective licenses.

The Future:
All source patches made to existing sources inside OI project and available on Github, can also land in respective source archive datasets.
But that would also require changing of a build process by putting archives first in folder and then building the component before publishing, but that could require build process changes, and is not the part of this Feature request.

Actions #1

Updated by Adam Števko over 6 years ago

  • Status changed from New to Rejected
  • % Done changed from 0 to 100

This was debated on the IRC and we agreed that there is not added value in this, so I am closing as Rejected.

Actions #2

Updated by Nikola M. over 6 years ago

Can you summarize, what you agreed on actually,
and how to provide source code availability for distributed snapshot releases , per snapshot and in between.


Also available in: Atom PDF