From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: persistent reproducibility ? Date: Thu, 23 Mar 2017 17:46:18 +0100 Message-ID: References: <87shm6wqju.fsf@gnu.org> <87k27grx6c.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cr5sV-0006AH-Pt for help-guix@gnu.org; Thu, 23 Mar 2017 12:46:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cr5sU-0008HQ-Cg for help-guix@gnu.org; Thu, 23 Mar 2017 12:46:23 -0400 In-Reply-To: <87k27grx6c.fsf@elephly.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ricardo Wurmus Cc: help-guix@gnu.org Hi! Thank you the details. >> One of the issues is that the Guix packages tree will never include >> some softwares, even if they are open source. Because the authors >> apply weird licences or non-GNU compliant licences, or simply because >> authors are not so motivated to push. Even if I totally agree with the >> paragraph about Proprietary Softwares in your cited paper, it is just >> a fact from my humble opinion. > > If you mean =E2=80=9Copen source=E2=80=9D in the sense of =E2=80=9Cusing = a license that is > certified by the Open Source Initiative=E2=80=9D then that software is pr= obably > Free Software. There is no such thing as GNU compliance in licenses. I mean "open source" any software publicly released with publicly accessible source. It is large. ;-) And I totally agree with the condition to be included or not in the Guix infrastructure. My point is that a lot of softwares released in scientific world will never reach such condition. It is sad and I think all people here are trying to change by convincing the authors. But, it is a pragmatic fact. Hum? I am not sure to get your point about GNU compliance. For example, https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Fre= e_System_Distribution_Guidelines `apt' and `debian-installer' illustrate the well-known and famous debate between RMS and Debian. :-) > > We do however follow the GNU FDSG (Free System Distribution Guidelines), > which may result in some software to be excluded or modified in rare > cases. (One example is =E2=80=9CShogun=E2=80=9D, which we modify to remo= ve included > non-free software.) Yes, the GNU FDSG defines "free" (as in speech). And there is "open source" softwares which are not included in this definition (for the good, for the bad, I am not arguing). https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses For example, some versions of Scilab (clone of Matlab) with a "weird" license (CeCILL-2). For the record, let indicate an historical point: https://www.gnu.org/licenses/bsd.html :-) I am not arguing about "bad" practices. I am just pointing that the situation of scientific softwares is often really complicated. Because they often glue a lot of different piece of softwares, e.g., https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D617931 Note that, in the same way that non-free parts are removed from `shogun', the guix package `gmsh' removes METIS non-free part (which is "open source"). Hope that this clarifies my point and feeds argument about channel. :-) > >> Therefore, what should be the "standard" way to manipulate against >> history version external and decentralised packages ? and guix repo >> packages too ? >> >> >> Well, if I understand your both answers, the correct process should >> be: Alice publishes a paper containing the exact version (commit hash >> or revision number or origin hash) of both the source tree and the >> recipe tree, and their both uri location, and then, Joe "just" needs >> to check out each (manually for now or possibly by nice UI glue). > > It would be sufficient to provide two things: a manifest and the Guix > version (=E2=80=9Cgit -C /path/to/guix.git describe=E2=80=9D). If additi= onal package > repositories are used (such as guix-bimsb for my institute), their > versions have to be recorded as well. Thank you to clarify the way. If I understand well, additional meta-data should be manually provided by A= lice. Extract a manifest is some UI glue, even, it is perhaps already possible. However, the Guix version do not appear to me straightforward. Does this information should be included when installing a package ? > > Joe would then check out Guix and any additional package repositories at > the specified versions and then instantiate the manifest. Provided that > all source tarballs are still obtainable (either directly or through a > mirror) and the builds are in fact bit-reproducible Joe would end up > with the same software environment that Alice fully specified in the > paper. Should be possible to extract all the required information from a profile with a kind of `guix pack' at the source level ? This should be useful ? or not at all and I am wishing a twisted process ? Thank you for your insights. And for sharing the MDC's configuration! All the best. -- simon > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net >