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).
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
