[oi-dev] Openindiana hipster source code on OI servers to fulfill licensing requirements.

[Nikola M]

On 10/15/15 07:09 AM, Jim Klimov wrote:
> On the converse side, git is relatively compact in comparison to tarballs. Given we have quite frequent builds of hipster that 'pkg update' is eager to download, storing gigabyt'ish tarballs can become prohibitive and impractical. Note we'd likely have to provide sources to third-party code (oi-userland) used for each release as well?
Of course. Every release has to have it's source visibly displayed and 
available
and it also can be done using GIT, yes with clear on-wiki instructions 
how to get them from OI servers, per package, per consolidation, per 
repository update/snapshot and per release.
That is also why having numbered updates ('entire' that locks both 
illumos and userland) is needed,
to also identify in the same manner the source that it came from.
Seems like GIT and having 'entire for every update' could be used for 
all that with not much effort and that source archives could be put into 
servers only for major releases.
> I think tags on the repo added for each released build should suffice.
That is true.  Just repo with full source before build should be on OI 
servers before building starts and available, so it could be easily 
tagged and available and that's it.
It is not Ok to just point to external archive source for source code on 
packages, let's mature.
It doesn't matter if front work is done on GIT from OI servers or 
Github, it is just important to replicate changes to OI GIT servers 
before building and publishing binaries.
> Are there 'source packages' in pkg(5) like there are for many other packaging systems?
This is a good question. Answer is that many packages in oi-userland 
started to provide separate package with sources, but that was 
abandoned, putting just external upstream source link and patches in 
git. That needs to change in a sense that also git is available on OI 
servers together with source form upstream.
You are on the right track, it could be done that way, to have sources 
also in packages beside binaries when publishing changes, but is not the 
only way to go, Git on OI server that includes upstream source and Git 
changes (and final source beforge megor releases) can be ebough.
> Perhaps, maintaining a pkg-repo of those for public revision (or even generating them and building binaries really from them) is a more useable way of providing the versioned sources to bits of each release (and on the backend, probably a lot from these weekly versions would be dedup'able). And there should be a package with the build procedure resources, as that bit also evolves and is needed to rebuild an exact copy (or as close as one can get).
It is definatevly a posibility it is just important that sources and 
binaries have same tags to be able to identify and get them synchronously.
If all packages are able to be installed from same binaries at the exact 
moment (that is what 'entire' for whole distro should provide and 
appropriate tags on sources) then you will have the exactly same 
environment that made that binary package and you will get the same 
binary package.

If thinking of building same binary on older build , while running newer 
OS, that could be made in branded zone. (don't think it could easily be 
done with packages only because of dependencies)
Generating branded zone is viable for only major releases and OI is not 
there yet, but sooner or later it will be (to be able to be supported 
and used in production).