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

[Jim Klimov]

15 октября 2015 г. 1:10:03 CEST, Hugo <hugo at myhomeemail.co.uk> пишет:
>Well put.
>
>  Original Message  
>From: Bob Friesenhahn
>Sent: Thursday, 15 October 2015 00:08
>To: OpenIndiana Developer mailing list
>Reply To: OpenIndiana Developer mailing list
>Subject: Re: [oi-dev] Openindiana hipster source code on OI servers to
>fulfill licensing requirements.
>
>On Wed, 14 Oct 2015, Nikola M wrote:
>>
>> It is a good question weither Oi got to have it's own source code 
>> repositories to match every Oi hipster 'snapshot' release. it does
>because 
>> source code distribution must be provided together with binary
>distribution, 
>> per licensing requirements of free software.
>
>I don't recall seeing a definition for how source code must be 
>distributed in any free software license. If the server is open for 
>all and the source is properly managed (e.g. clear release notes and 
>repository tags and or branches), is that necessarily inferior to 
>tarballs provided by ftp or http?
>
>There does need to be a precise way to obtain the exact sources used 
>to build any binary release and it should be documented.
>
>Regardless, directories of tarballs seem best since they are easiest 
>to copy and therefore less likely to be lost.
>
>Bob

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?

I think tags on the repo added for each released build should suffice.

Are there 'source packages' in pkg(5) like there are for many other packaging systems? 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).

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android