Hi all,
I'd like to propose a new SIG for the OCaml language.
OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4].
The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6].
A number of people have already agreed that they are interested and may be able to help (all CC'd):
From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/):
- Anil Madhavapeddy - Thomas Gazagnaire
From Jane Street (https://www.janestreet.com/):
- Yaron Minsky - Dominick LoBraico
From Citrix (https://www.citrix.com/):
- Me - Euan Harris
From OCamlPro (http://www.ocamlpro.com/):
- Louis Gesbert
Comments?
Jon
[1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot
On 11/19/2014 07:20 AM, Jon Ludlam wrote:
Hi all,
I'd like to propose a new SIG for the OCaml language.
OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4].
The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6].
A number of people have already agreed that they are interested and may be able to help (all CC'd):
From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/):
- Anil Madhavapeddy
- Thomas Gazagnaire
From Jane Street (https://www.janestreet.com/):
- Yaron Minsky
- Dominick LoBraico
From Citrix (https://www.citrix.com/):
- Me
- Euan Harris
From OCamlPro (http://www.ocamlpro.com/):
- Louis Gesbert
Comments?
Jon
[1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot
We might be able to do this as part of the current Virt SIG if everyone there agrees.
I know that we want to use a newer OCaml for xen on both c6 and c7.
Thanks, Johnny Hughes
On 19/11/14 15:06, Johnny Hughes wrote:
On 11/19/2014 07:20 AM, Jon Ludlam wrote:
Hi all,
I'd like to propose a new SIG for the OCaml language.
OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4].
The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6].
A number of people have already agreed that they are interested and may be able to help (all CC'd):
From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/):
- Anil Madhavapeddy
- Thomas Gazagnaire
From Jane Street (https://www.janestreet.com/):
- Yaron Minsky
- Dominick LoBraico
From Citrix (https://www.citrix.com/):
- Me
- Euan Harris
From OCamlPro (http://www.ocamlpro.com/):
- Louis Gesbert
Comments?
Jon
[1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot
We might be able to do this as part of the current Virt SIG if everyone there agrees.
I know that we want to use a newer OCaml for xen on both c6 and c7.
The reason I was thinking of a separate SIG is that a number of the interested parties I listed don't care as much as I do about virtualisation, and so a more general SIG seemed appropriate. Even though here at Citrix our focus is virtualisation, of the ~120 SRPMs we build for the XenServer buildroot project around 80 are entirely generic OCaml libraries that may well be of use to other people outside of the virtualisation area. An OCaml SIG would avoid muddying the waters by including a large number of seemingly irrelevant RPMs in the Virt SIG.
Jon
Thanks, Johnny Hughes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2014 09:06 AM, Johnny Hughes wrote:
We might be able to do this as part of the current Virt SIG if everyone there agrees.
This may be where the tiered approach helps, as OCaml certainly isn't limited to virt. If we create a new SIG for OCaml, it could then be something the Virt SIG consumes in order to build, assuming they agreed.
- -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77
On 11/19/2014 07:20 AM, Jon Ludlam wrote:
Hi all,
I'd like to propose a new SIG for the OCaml language.
OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4].
The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6].
A number of people have already agreed that they are interested and may be able to help (all CC'd):
From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/):
- Anil Madhavapeddy
- Thomas Gazagnaire
From Jane Street (https://www.janestreet.com/):
- Yaron Minsky
- Dominick LoBraico
From Citrix (https://www.citrix.com/):
- Me
- Euan Harris
From OCamlPro (http://www.ocamlpro.com/):
- Louis Gesbert
Comments?
Jon
[1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot
This seems like a very good start to the proposal. A few questions/statements:
1. What would you require in terms of distribution resources? I'm assuming git/koji access, so that you could build and distribute sig packages.
1a. Would you require a mailing list or forum area?
2. What do you envision for release planning? Tracking upstream builds vs a newer stabilized release?
3. How would releases be built/scheduled? Build every month, every 6 months, "when something happens upstream" ?
4. Testing? How would you validate package builds? Are test suites included as part of the source, or would you consider implementing some form of test suite criteria to ensure builds do the right thing?
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Jim Perrin Sent: 19 November 2014 4:13 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] RFC: OCaml SIG
On 11/19/2014 07:20 AM, Jon Ludlam wrote:
Hi all,
I'd like to propose a new SIG for the OCaml language.
OCaml is an industrial strength programming language supporting
functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4].
The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010),
and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6].
A number of people have already agreed that they are interested and may
be able to help (all CC'd):
From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/):
- Anil Madhavapeddy
- Thomas Gazagnaire
From Jane Street (https://www.janestreet.com/):
- Yaron Minsky
- Dominick LoBraico
From Citrix (https://www.citrix.com/):
- Me
- Euan Harris
From OCamlPro (http://www.ocamlpro.com/):
- Louis Gesbert
Comments?
Jon
[1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries,
etc.
[3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm assuming
git/koji access, so that you could build and distribute sig packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream builds vs a
newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too frequent. I suspect a monthly cadence would be right to begin with.
- Testing? How would you validate package builds? Are test suites included
as part of the source, or would you consider implementing some form of test suite criteria to ensure builds do the right thing?
Many of the libraries that are obvious candidates right now have test suites designed to be run by travis - we can certainly ensure these are run as part of the build. Citrix could also run tests on any candidate changes before they get pushed by building, which may be helpful.
Jon
On 11/20/2014 07:41 AM, Jonathan Ludlam wrote:
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm assuming
git/koji access, so that you could build and distribute sig packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream builds vs a
newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too frequent. I suspect a monthly cadence would be right to begin with.
In thinking about this a bit more (and based on the pace of upstream you mention), it seems like this might be something which could be done via software collections. That way if there's a compatibility break for some reason, users would be able to have both an older and current version. Would you be willing to do this as part of a software collection?
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Jim Perrin Sent: 20 November 2014 2:29 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] RFC: OCaml SIG
On 11/20/2014 07:41 AM, Jonathan Ludlam wrote:
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm
assuming git/koji access, so that you could build and distribute sig
packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the
forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream
builds vs a newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For
critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too
frequent. I suspect a monthly cadence would be right to begin with.
In thinking about this a bit more (and based on the pace of upstream you mention), it seems like this might be something which could be done via software collections. That way if there's a compatibility break for some reason, users would be able to have both an older and current version. Would you be willing to do this as part of a software collection?
I imagine so; my only concern would be whether we can have the Virt SIG depend upon a software collection, as Johnny Hughes already mentioned a desire to have the Xen builds depend upon a newer version of OCaml. Is this feasible in the same way that SIGs can depend upon each other?
Jon
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/20/2014 10:08 AM, Jonathan Ludlam wrote:
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Jim Perrin Sent: 20 November 2014 2:29 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] RFC: OCaml SIG
On 11/20/2014 07:41 AM, Jonathan Ludlam wrote:
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm
assuming git/koji access, so that you could build and distribute sig
packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the
forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream
builds vs a newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For
critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too
frequent. I suspect a monthly cadence would be right to begin with.
In thinking about this a bit more (and based on the pace of upstream you mention), it seems like this might be something which could be done via software collections. That way if there's a compatibility break for some reason, users would be able to have both an older and current version. Would you be willing to do this as part of a software collection?
I imagine so; my only concern would be whether we can have the Virt SIG depend upon a software collection, as Johnny Hughes already mentioned a desire to have the Xen builds depend upon a newer version of OCaml. Is this feasible in the same way that SIGs can depend upon each other?
Jon
I think we can do it as an SCL and even as part of the SCL SIG
We should be able to change the ocaml requires in the xen SPEC to use the SCL (and include scl-utils) and modify the xen startup scripts to call the correct variables from the SCL to set everything up on startup.
On 20 Nov 2014, at 17:49, Johnny Hughes johnny@centos.org wrote:
On 11/20/2014 10:08 AM, Jonathan Ludlam wrote:
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Jim Perrin Sent: 20 November 2014 2:29 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] RFC: OCaml SIG
On 11/20/2014 07:41 AM, Jonathan Ludlam wrote:
This seems like a very good start to the proposal. A few questions/statements:
- What would you require in terms of distribution resources? I'm
assuming git/koji access, so that you could build and distribute sig
packages.
That sounds right.
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the
forum area, but others may disagree.
- What do you envision for release planning? Tracking upstream
builds vs a newer stabilized release?
I would imagine this decision being taken on a case-by-case basis. For
critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen.
- How would releases be built/scheduled? Build every month, every 6
months, "when something happens upstream" ?
Things happen upstream quite rapidly at the moment, so that would be too
frequent. I suspect a monthly cadence would be right to begin with.
In thinking about this a bit more (and based on the pace of upstream you mention), it seems like this might be something which could be done via software collections. That way if there's a compatibility break for some reason, users would be able to have both an older and current version. Would you be willing to do this as part of a software collection?
I imagine so; my only concern would be whether we can have the Virt SIG depend upon a software collection, as Johnny Hughes already mentioned a desire to have the Xen builds depend upon a newer version of OCaml. Is this feasible in the same way that SIGs can depend upon each other?
Jon
I think we can do it as an SCL and even as part of the SCL SIG
We should be able to change the ocaml requires in the xen SPEC to use the SCL (and include scl-utils) and modify the xen startup scripts to call the correct variables from the SCL to set everything up on startup.
In which case, I see no problem with this approach. What are the next steps?
Jon
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/20/2014 12:24 PM, Jonathan Ludlam wrote: <snipping>
I think we can do it as an SCL and even as part of the SCL SIG
We should be able to change the ocaml requires in the xen SPEC to use the SCL (and include scl-utils) and modify the xen startup scripts to call the correct variables from the SCL to set everything up on startup.
In which case, I see no problem with this approach. What are the next steps?
We as a board voted to approve the SCL sig yesterday. We need to work out git access with them, but meanwhile we can start looking at what it would take to convert it to software collections and testing via scratch builds so that it's ready to go once the SCL sig kicks off.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/20/2014 10:43 AM, Jim Perrin wrote:
On 11/20/2014 12:24 PM, Jonathan Ludlam wrote: <snipping>
I think we can do it as an SCL and even as part of the SCL SIG
We should be able to change the ocaml requires in the xen SPEC to use the SCL (and include scl-utils) and modify the xen startup scripts to call the correct variables from the SCL to set everything up on startup.
In which case, I see no problem with this approach. What are the next steps?
We as a board voted to approve the SCL sig yesterday. We need to work out git access with them, but meanwhile we can start looking at what it would take to convert it to software collections and testing via scratch builds so that it's ready to go once the SCL sig kicks off.
Yeah, I like the idea of bringing this in to the SCL SIG. (The other thought I had was to do sort-of Programming SIG with specialists to maintain and grow community around various languages, but then I realized that started to sound like the SCL SIG ...)
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Thu, Nov 20, 2014 at 11:22:27AM -0800, Karsten Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/20/2014 10:43 AM, Jim Perrin wrote:
On 11/20/2014 12:24 PM, Jonathan Ludlam wrote: <snipping>
I think we can do it as an SCL and even as part of the SCL SIG
We should be able to change the ocaml requires in the xen SPEC to use the SCL (and include scl-utils) and modify the xen startup scripts to call the correct variables from the SCL to set everything up on startup.
In which case, I see no problem with this approach. What are the next steps?
We as a board voted to approve the SCL sig yesterday. We need to work out git access with them, but meanwhile we can start looking at what it would take to convert it to software collections and testing via scratch builds so that it's ready to go once the SCL sig kicks off.
Yeah, I like the idea of bringing this in to the SCL SIG. (The other thought I had was to do sort-of Programming SIG with specialists to maintain and grow community around various languages, but then I realized that started to sound like the SCL SIG ...)
I've had a go at making an SCL of the latest OCaml release, which seems to be working OK so far. I'd quite like to get some feedback, to see if I'm going about things the right way. The SPECS and SOURCES are on github: https://github.com/jonludlam/ocaml4021-buildroot and I've been building for CentOS 7 and 6 on copr: https://copr.fedoraproject.org/coprs/jonludlam/ocaml4021/
Comments and bug reports very welcome!
Jon
On 12/08/2014 04:52 PM, Jon Ludlam wrote:
I've had a go at making an SCL of the latest OCaml release, which seems to be working OK so far. I'd quite like to get some feedback, to see if I'm going about things the right way. The SPECS and SOURCES are on github: https://github.com/jonludlam/ocaml4021-buildroot and I've been building for CentOS 7 and 6 on copr: https://copr.fedoraproject.org/coprs/jonludlam/ocaml4021/
Comments and bug reports very welcome!
Excellent! We're working out the details for getting the scl.org folks set up. Once we have the basics in place, it would be great to have this pulled in. In the mean time, we can certainly kick the packages around a bit. Thanks very much for this.
On 12/09/2014 12:10 AM, Jim Perrin wrote:
On 12/08/2014 04:52 PM, Jon Ludlam wrote:
I've had a go at making an SCL of the latest OCaml release, which seems to be working OK so far. I'd quite like to get some feedback, to see if I'm going about things the right way. The SPECS and SOURCES are on github: https://github.com/jonludlam/ocaml4021-buildroot and I've been building for CentOS 7 and 6 on copr: https://copr.fedoraproject.org/coprs/jonludlam/ocaml4021/
Comments and bug reports very welcome!
Hi Jon,
great to see a new SCL, good work! I have couple of notes for consideration..
* the collection name looks like it includes minor version of ocaml as well; might be correct, depending on ocaml versioning policy, but generally the version should only use the part of the version that likely changes if some incompatible change comes -- thus e.g. for python we only use two numbers (python27), not three (python274), since the latest bugfix release do not include incompatible changes and we can update them
* then I see couple of provides that do not include scl version, e.g.: ocaml(Ssl_threads) = 9925dd2c278261461f67ee0f74f4149a I guess it means that some non-SCL ocaml package could be satisfied with SCL package, which doesn't feel right. We rather require sclname in all provides somehow
Honza
Excellent! We're working out the details for getting the scl.org folks set up. Once we have the basics in place, it would be great to have this pulled in. In the mean time, we can certainly kick the packages around a bit. Thanks very much for this.
On Wed, Dec 10, 2014 at 07:02:01PM +0100, Honza Horak wrote:
On 12/09/2014 12:10 AM, Jim Perrin wrote:
On 12/08/2014 04:52 PM, Jon Ludlam wrote:
I've had a go at making an SCL of the latest OCaml release, which seems to be working OK so far. I'd quite like to get some feedback, to see if I'm going about things the right way. The SPECS and SOURCES are on github: https://github.com/jonludlam/ocaml4021-buildroot and I've been building for CentOS 7 and 6 on copr: https://copr.fedoraproject.org/coprs/jonludlam/ocaml4021/
Comments and bug reports very welcome!
Hi Jon,
great to see a new SCL, good work! I have couple of notes for consideration..
- the collection name looks like it includes minor version of ocaml
as well; might be correct, depending on ocaml versioning policy, but generally the version should only use the part of the version that likely changes if some incompatible change comes -- thus e.g. for python we only use two numbers (python27), not three (python274), since the latest bugfix release do not include incompatible changes and we can update them
Makes sense - I'll double check what the upstream policy is on numbers and then likely change it.
- then I see couple of provides that do not include scl version,
e.g.: ocaml(Ssl_threads) = 9925dd2c278261461f67ee0f74f4149a I guess it means that some non-SCL ocaml package could be satisfied with SCL package, which doesn't feel right. We rather require sclname in all provides somehow
Hmm, this is interesting. The requires/prodides are (almost) all generated, and they are extremely brittle. The fedora packaging wiki mentions here (https://fedoraproject.org/wiki/Packaging:OCaml) that OCaml "OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)", and that this mechanism "enforces the same requirements as the OCaml linker itself". I _think_ the likelihood of a collision between an SCL and non-SCL package is almost certainly zero, but I should investigate this a bit more.
Thanks for the feedback!
Jon
Honza
Excellent! We're working out the details for getting the scl.org folks set up. Once we have the basics in place, it would be great to have this pulled in. In the mean time, we can certainly kick the packages around a bit. Thanks very much for this.
On 12/10/2014 07:47 PM, Jon Ludlam wrote:
- then I see couple of provides that do not include scl version,
e.g.: ocaml(Ssl_threads) = 9925dd2c278261461f67ee0f74f4149a I guess it means that some non-SCL ocaml package could be satisfied with SCL package, which doesn't feel right. We rather require sclname in all provides somehow
Hmm, this is interesting. The requires/prodides are (almost) all generated, and they are extremely brittle. The fedora packaging wiki mentions here (https://fedoraproject.org/wiki/Packaging:OCaml) that OCaml "OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)", and that this mechanism "enforces the same requirements as the OCaml linker itself". I_think_ the likelihood of a collision between an SCL and non-SCL package is almost certainly zero, but I should investigate this a bit more.
Ok, the hash may help in this case to avoid a false package is installed. But isn't it still possible someone asks for just unversioned provide (e.g. 'ocaml(Text)') and expects non-SCL package to be installed?
Honza
On Thu, Dec 11, 2014 at 07:38:36AM +0100, Honza Horak wrote:
On 12/10/2014 07:47 PM, Jon Ludlam wrote:
- then I see couple of provides that do not include scl version,
e.g.: ocaml(Ssl_threads) = 9925dd2c278261461f67ee0f74f4149a I guess it means that some non-SCL ocaml package could be satisfied with SCL package, which doesn't feel right. We rather require sclname in all provides somehow
Hmm, this is interesting. The requires/prodides are (almost) all generated, and they are extremely brittle. The fedora packaging wiki mentions here (https://fedoraproject.org/wiki/Packaging:OCaml) that OCaml "OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)", and that this mechanism "enforces the same requirements as the OCaml linker itself". I_think_ the likelihood of a collision between an SCL and non-SCL package is almost certainly zero, but I should investigate this a bit more.
Ok, the hash may help in this case to avoid a false package is installed. But isn't it still possible someone asks for just unversioned provide (e.g. 'ocaml(Text)') and expects non-SCL package to be installed?
I don't believe anyone would or should ever do that. The requires lines of the form "ocaml(...)" are generated automatically. Explicit dependencies in the spec file should be depending on the RPM package name rather than a particular module name that's being provided, and the RPM package names _will_ have the {?scl_prefix} before them. Perhaps the easiest thing to do is to see whether any packages do this already?
Also, there is some related interesting discussion on BZ ticket here: https://bugzilla.redhat.com/show_bug.cgi?id=460872
Jon
On 12/11/2014 12:38 AM, Honza Horak wrote:
Ok, the hash may help in this case to avoid a false package is installed. But isn't it still possible someone asks for just unversioned provide (e.g. 'ocaml(Text)') and expects non-SCL package to be installed?
It seems like everyone's willing to accept this(fix discussion vs acceptance discussion), so what should the repo be named and branched?
On Thu, Nov 20, 2014 at 1:41 PM, Jonathan Ludlam Jonathan.Ludlam@citrix.com wrote:
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the forum area, but others may disagree.
FWIW, the virt sig doesn't seem to use our mailing list all that much -- would it make sense to keep discussions on centos-devel until it becomes obvious that the ocaml-related traffic is high enough to warrant its own list?
-George
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of George Dunlap Sent: 20 November 2014 3:10 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] RFC: OCaml SIG
On Thu, Nov 20, 2014 at 1:41 PM, Jonathan Ludlam Jonathan.Ludlam@citrix.com wrote:
1a. Would you require a mailing list or forum area?
I think a mailing list would be helpful. Personally I'm less bothered by the
forum area, but others may disagree.
FWIW, the virt sig doesn't seem to use our mailing list all that much -- would it make sense to keep discussions on centos-devel until it becomes obvious that the ocaml-related traffic is high enough to warrant its own list?
Sure, that seems sensible.
Jon
-George _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
George Dunlap -
Honza Horak -
Jim Perrin -
Johnny Hughes -
Jon Ludlam -
Jonathan Ludlam
-
Karsten Wade