[aur-general] Ocaml Packages
I am looking at the state of the ArchLinux Ocaml packages. I am trying to update a number of them and I am trying to build a number of ocaml applications, but there are many incosistencies. The main problem is that there are ocaml packages that build with findlib and without findlib, and they place the development libs in different places. Also I have found a few packages that install libs in the findlib dir AND in the ocaml dir. The two directories are : findlib: /usr/lib/ocaml/site-lib non-findlib: /usr/lib/ocaml Other distributions with more developed ocaml support, such as fedora and Debian/Ubuntu have chosen to use findlib for all packages and they all install to the /usr/lib/ocaml dir. So I am proposing for discussion, that we look into repairing the ocaml packages to all use findlib and to install everything into /usr/lib/ocaml. Then we can have some peace on the ocaml front and we can do away with the complications in the AUR with ocaml packages. I have adopted the ocaml-findlib package and a number of them have been orphaned, (which I am picking up) but I wanted to run this by the TUs and other AUR devs before I really considered revamping the ocaml landscape in the AUR. -Thanks -Thomas S Hatch
Thomas S Hatch wrote:
I am looking at the state of the ArchLinux Ocaml packages. I am trying to update a number of them and I am trying to build a number of ocaml applications, but there are many incosistencies.
The main problem is that there are ocaml packages that build with findlib and without findlib, and they place the development libs in different places. Also I have found a few packages that install libs in the findlib dir AND in the ocaml dir.
The two directories are : findlib: /usr/lib/ocaml/site-lib non-findlib: /usr/lib/ocaml
Other distributions with more developed ocaml support, such as fedora and Debian/Ubuntu have chosen to use findlib for all packages and they all install to the /usr/lib/ocaml dir.
So I am proposing for discussion, that we look into repairing the ocaml packages to all use findlib and to install everything into /usr/lib/ocaml. Then we can have some peace on the ocaml front and we can do away with the complications in the AUR with ocaml packages.
I have adopted the ocaml-findlib package and a number of them have been orphaned, (which I am picking up) but I wanted to run this by the TUs and other AUR devs before I really considered revamping the ocaml landscape in the AUR.
-Thanks
-Thomas S Hatch
Standardizing the OCaml packages and bringing them in line with other distributions would be good. You should probably add a page to the wiki to document OCaml packaging guidelines. Include a link to guidelines among the others on the packaging standards page: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards While searching for existing OCaml guidelines in the wiki I found the following post, which may or may not be useful: https://bbs.archlinux.org/viewtopic.php?id=88588 Regards, Xyne
On Sat, Jan 1, 2011 at 12:38 PM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
I am looking at the state of the ArchLinux Ocaml packages. I am trying to update a number of them and I am trying to build a number of ocaml applications, but there are many incosistencies.
The main problem is that there are ocaml packages that build with findlib and without findlib, and they place the development libs in different places. Also I have found a few packages that install libs in the findlib dir AND in the ocaml dir.
The two directories are : findlib: /usr/lib/ocaml/site-lib non-findlib: /usr/lib/ocaml
Other distributions with more developed ocaml support, such as fedora and Debian/Ubuntu have chosen to use findlib for all packages and they all install to the /usr/lib/ocaml dir.
So I am proposing for discussion, that we look into repairing the ocaml packages to all use findlib and to install everything into /usr/lib/ocaml. Then we can have some peace on the ocaml front and we can do away with the complications in the AUR with ocaml packages.
I have adopted the ocaml-findlib package and a number of them have been orphaned, (which I am picking up) but I wanted to run this by the TUs and other AUR devs before I really considered revamping the ocaml landscape in the AUR.
-Thanks
-Thomas S Hatch
Standardizing the OCaml packages and bringing them in line with other distributions would be good.
You should probably add a page to the wiki to document OCaml packaging guidelines. Include a link to guidelines among the others on the packaging standards page: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards
While searching for existing OCaml guidelines in the wiki I found the following post, which may or may not be useful: https://bbs.archlinux.org/viewtopic.php?id=88588
Regards, Xyne
Thanks Xyne, that helps, I am going to try and figure out the best way to change the ocaml packaging process without just breaking all of the OCaml packages, i will have the guidelines up shortly and star t moving towards clean ArchLinux Ocaml. -Thomas S Hatch
Thomas S Hatch wrote:
Thanks Xyne, that helps, I am going to try and figure out the best way to change the ocaml packaging process without just breaking all of the OCaml packages, i will have the guidelines up shortly and star t moving towards clean ArchLinux Ocaml.
-Thomas S Hatch
There seems to be only 6 OCaml packages in the repos: lablgtk lablgtk2 ocaml camlp5 camlp5-transitional llvm-ocaml Check if they follow the guidelines that you propose and contact the maintainers of any that don't. If you explain the situation and provide a patch then you'll probably get a quick and positive response. Before you do, consider whether the names need to be changed. Most library packages follow the convention of including the language name as a prefix, e.g. "perl-foo" or "haskell-bar". What's the state of the ocaml packages? lablgtk should probably be ocaml-lablgtk, etc. Consider how few packages there are in the repos, I doubt there would be much opposition to fixing clearly broken names. Regards, Xyne
On Sat, Jan 1, 2011 at 12:58 PM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
Thanks Xyne, that helps, I am going to try and figure out the best way to change the ocaml packaging process without just breaking all of the OCaml packages, i will have the guidelines up shortly and star t moving towards clean ArchLinux Ocaml.
-Thomas S Hatch
There seems to be only 6 OCaml packages in the repos:
lablgtk lablgtk2 ocaml camlp5 camlp5-transitional llvm-ocaml
Check if they follow the guidelines that you propose and contact the maintainers of any that don't. If you explain the situation and provide a patch then you'll probably get a quick and positive response.
Before you do, consider whether the names need to be changed. Most library packages follow the convention of including the language name as a prefix, e.g. "perl-foo" or "haskell-bar". What's the state of the ocaml packages?
lablgtk should probably be ocaml-lablgtk, etc. Consider how few packages there are in the repos, I doubt there would be much opposition to fixing clearly broken names.
Regards, Xyne
Thanks again Xyne, will do. As for the naming of ocaml packages roght now, often there are duplicates in the AUR, I will put that down on my list to hunt down problems! -Thomas S Hatch
I have updated ocaml-findlib and about 10 more ocaml packages with this changes, I have also started to the spread the word on this move and I have been met with positive responses. I have a simple OCaml Package guidelines page up on the wiki: https://wiki.archlinux.org/index.php/OCaml_Package_Guidelines This is already making PKGBUILDs for ocaml simpler and has repaired a number of build issues in packages. I am going to talk to the upstream maintainers, but I think that all I will be requesting is a name change on a few packages. BTW, how far along should I be before I apply to be a TU? -Thomas S Hatch On Sat, Jan 1, 2011 at 1:01 PM, Thomas S Hatch <thatch45@gmail.com> wrote:
On Sat, Jan 1, 2011 at 12:58 PM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
Thanks Xyne, that helps, I am going to try and figure out the best way to change the ocaml packaging process without just breaking all of the OCaml packages, i will have the guidelines up shortly and star t moving towards clean ArchLinux Ocaml.
-Thomas S Hatch
There seems to be only 6 OCaml packages in the repos:
lablgtk lablgtk2 ocaml camlp5 camlp5-transitional llvm-ocaml
Check if they follow the guidelines that you propose and contact the maintainers of any that don't. If you explain the situation and provide a patch then you'll probably get a quick and positive response.
Before you do, consider whether the names need to be changed. Most library packages follow the convention of including the language name as a prefix, e.g. "perl-foo" or "haskell-bar". What's the state of the ocaml packages?
lablgtk should probably be ocaml-lablgtk, etc. Consider how few packages there are in the repos, I doubt there would be much opposition to fixing clearly broken names.
Regards, Xyne
Thanks again Xyne, will do. As for the naming of ocaml packages roght now, often there are duplicates in the AUR, I will put that down on my list to hunt down problems!
-Thomas S Hatch
On 2011-01-01 20:56 -0700 (00:6) Thomas S Hatch wrote:
I have updated ocaml-findlib and about 10 more ocaml packages with this changes, I have also started to the spread the word on this move and I have been met with positive responses.
I have a simple OCaml Package guidelines page up on the wiki: https://wiki.archlinux.org/index.php/OCaml_Package_Guidelines
I've made some changes to the page: * reworded "OCaml Library Locations" section for clarity and emphasis * added architecture recommendation to "Bytecode" section (I presume that if a package does not produce bytecode then it should specify "any" as its architecture.) * cleaned up the PKGBUILD - added double quotation marks to all variables - moved "ocaml" from makedepends to depends The latter might require some updates to existing PKGBUILDs.
This is already making PKGBUILDs for ocaml simpler and has repaired a number of build issues in packages.
I am going to talk to the upstream maintainers, but I think that all I will be requesting is a name change on a few packages.
ocaml-findlib will eventually need to be moved to [extra] by a dev if it is to be required by all OCaml packages. I suggest that you contact the maintainer of the OCaml package about this as the two should logically be maintained together.
BTW, how far along should I be before I apply to be a TU?
I can't believe that you top-posted for the first time when asking this question. Talk about shooting yourself in the foot. :P Regards, Xyne
On Sun, Jan 2, 2011 at 2:40 AM, Xyne <xyne@archlinux.ca> wrote:
On 2011-01-01 20:56 -0700 (00:6) Thomas S Hatch wrote:
I have updated ocaml-findlib and about 10 more ocaml packages with this changes, I have also started to the spread the word on this move and I have been met with positive responses.
I have a simple OCaml Package guidelines page up on the wiki: https://wiki.archlinux.org/index.php/OCaml_Package_Guidelines
I've made some changes to the page: * reworded "OCaml Library Locations" section for clarity and emphasis * added architecture recommendation to "Bytecode" section (I presume that if a package does not produce bytecode then it should specify "any" as its architecture.) * cleaned up the PKGBUILD - added double quotation marks to all variables - moved "ocaml" from makedepends to depends
The latter might require some updates to existing PKGBUILDs.
This is already making PKGBUILDs for ocaml simpler and has repaired a number of build issues in packages.
I am going to talk to the upstream maintainers, but I think that all I will be requesting is a name change on a few packages.
ocaml-findlib will eventually need to be moved to [extra] by a dev if it is to be required by all OCaml packages. I suggest that you contact the maintainer of the OCaml package about this as the two should logically be maintained together.
BTW, how far along should I be before I apply to be a TU?
I can't believe that you top-posted for the first time when asking this question. Talk about shooting yourself in the foot. :P
Regards, Xyne
Yes, I top posted, I need to fix that on my phone. I changed the bytecode changes you made, maybe it will make more sense to you now how ocaml bytecode works. I added ocaml back to the makedepends, the ocaml package provides the compiler. OCaml should only be a dependency when the package includes bytecode, since ocaml executables are %100 native machine code - this is an error in most OCaml packages (I need to fix a number of mine) Thanks for the PKGBUILD fixes and the change in the tone and detail on the ocaml library locations section. Oh, and BTW... How far along should I be before I apply to be a TU? :) -Thomas S Hatch
Thomas S Hatch wrote:
I changed the bytecode changes you made, maybe it will make more sense to you now how ocaml bytecode works.
Ah, sorry. It's clearer now.
I added ocaml back to the makedepends, the ocaml package provides the compiler.
OCaml should only be a dependency when the package includes bytecode, since ocaml executables are %100 native machine code - this is an error in most OCaml packages (I need to fix a number of mine)
If the resulting package does not require ocaml then it should not be named "ocaml-*". It was my understanding that these packages were OCaml libraries, i.e. code and/or binaries that should be used within OCaml code. Maybe there is a misunderstanding about makedepends vs depends. If a package is required both to build and to run another package, then it should be included in the depends array. If the package is only required to build the package but not to run it then it should be included in the makedepends array. So if the resulting packages are stand-alone executables or generic libraries then they should not be named "ocaml-*" any more than anything written in C should be named "c-*". If they are only for use with OCaml then ocaml should be a dependency and the name should retain the "ocaml-" prefix.
Oh, and BTW... How far along should I be before I apply to be a TU? :) I'd say you're almost there, but I want to see how this discussion goes before I say anything more. ;)
Regards, Xyne
On Mon, Jan 3, 2011 at 4:02 AM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
I changed the bytecode changes you made, maybe it will make more sense to you now how ocaml bytecode works.
Ah, sorry. It's clearer now.
I added ocaml back to the makedepends, the ocaml package provides the compiler.
OCaml should only be a dependency when the package includes bytecode, since ocaml executables are %100 native machine code - this is an error in most OCaml packages (I need to fix a number of mine)
If the resulting package does not require ocaml then it should not be named "ocaml-*". It was my understanding that these packages were OCaml libraries, i.e. code and/or binaries that should be used within OCaml code.
Maybe there is a misunderstanding about makedepends vs depends. If a package is required both to build and to run another package, then it should be included in the depends array. If the package is only required to build the package but not to run it then it should be included in the makedepends array.
So if the resulting packages are stand-alone executables or generic libraries then they should not be named "ocaml-*" any more than anything written in C should be named "c-*". If they are only for use with OCaml then ocaml should be a dependency and the name should retain the "ocaml-" prefix.
Oh, and BTW... How far along should I be before I apply to be a TU? :) I'd say you're almost there, but I want to see how this discussion goes before I say anything more. ;)
Regards, Xyne
Sounds good, in the case of OCaml libs, using the libs will almost always require the ocaml package, actually, the only cases where it would not is if the upstream maintainer is not producing bytecode and native bins, which they always should. So you are most likely correct in that we should recommended ocaml as a dep and a makedep, and I think we should keep the naming, not only because of the ocaml dependencies, but also to distinguish them from the C libs, it would not take long before we started to see naming conflicts since many libs provide the same functions by the same names. So with that said I think I need to clarify that packages like virt-top ( http://aur.archlinux.org/packages.php?ID=44978) which distribute only a native executable need to NOT be called ocaml-virt-top but since the libs should distribute code for all three layers and that running said code requires the ocaml package. I think that my main problem is that I underestimated the clarity needed on the documentation, something which should never be done, and that OCaml builds can be a little more complicated because of the layers. Also I am trying to bring the conventions inline with the way they were created by Richard Jones for Red Hat, since they are very clean and Richard Jones is one of the main OCaml heads. Does that make sense? I think that you are right on the depends for libs, and that the naming should stay ocaml-foo for libs. But clarify in the docs that OCaml applications should be treated like normal applications since they should not require ocaml. The viable confusion comes in where an end user application is built in such a way that it uses the bytecode - I have never seen this, but it is possible. I will look over the wiki page and look to add more clarity. -Tom
Thomas S Hatch wrote:
Sounds good, in the case of OCaml libs, using the libs will almost always require the ocaml package, actually, the only cases where it would not is if the upstream maintainer is not producing bytecode and native bins, which they always should. So you are most likely correct in that we should recommended ocaml as a dep and a makedep, and I think we should keep the naming, not only because of the ocaml dependencies, but also to distinguish them from the C libs, it would not take long before we started to see naming conflicts since many libs provide the same functions by the same names.
Sorry, I should have been clearer in my previous message. A package should *never* appear in both the depends and the makedepends array. If a package is required both to build and to run it, it should appear in, and only in, the depends array. If it's only needed to build the package but not to run it then it should be in the makedepends array. I have edited the Wiki page to remove "ocaml" from the makedepends array. Perhaps it should be made clearer on the wiki page that the example PKGBUILD is only for OCaml libraries.
So with that said I think I need to clarify that packages like virt-top ( http://aur.archlinux.org/packages.php?ID=44978) which distribute only a native executable need to NOT be called ocaml-virt-top but since the libs should distribute code for all three layers and that running said code requires the ocaml package.
*nods*
Also I am trying to bring the conventions inline with the way they were created by Richard Jones for Red Hat, since they are very clean and Richard Jones is one of the main OCaml heads.
Does that make sense? I think that you are right on the depends for libs, and that the naming should stay ocaml-foo for libs. But clarify in the docs that OCaml applications should be treated like normal applications since they should not require ocaml.
*nods again*
The viable confusion comes in where an end user application is built in such a way that it uses the bytecode - I have never seen this, but it is possible.
If the bytecode were an application then I would not include the "ocaml-" prefix in the name, assuming that no libraries were included. The "ocaml-" prefix should indicate that the package is for working with OCaml, i.e. that it provides something which is only useful to an OCaml coder, which will normally be a library, or something else that you can import in your code. If the package provides a an executable that the user can use without caring about the language behind it, then it should not contain the prefix. That applies to bytecode as well, as the user need not be concerned with the underlying code. For packages that mix both libraries and applications, it can go either way. I would opt for using the prefix in that case to indicate the presence of libraries, but I know that there are some Haskell packages which use the binary's name without the "haskell-" prefix despite the inclusion of libraries. There's probably a better, pithier way to express this, but it eludes me right now.
On Tue, Jan 4, 2011 at 9:46 AM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
Sounds good, in the case of OCaml libs, using the libs will almost always require the ocaml package, actually, the only cases where it would not is if the upstream maintainer is not producing bytecode and native bins, which they always should. So you are most likely correct in that we should recommended ocaml as a dep and a makedep, and I think we should keep the naming, not only because of the ocaml dependencies, but also to distinguish them from the C libs, it would not take long before we started to see naming conflicts since many libs provide the same functions by the same names.
Sorry, I should have been clearer in my previous message. A package should *never* appear in both the depends and the makedepends array. If a package is required both to build and to run it, it should appear in, and only in, the depends array. If it's only needed to build the package but not to run it then it should be in the makedepends array.
I have edited the Wiki page to remove "ocaml" from the makedepends array.
Perhaps it should be made clearer on the wiki page that the example PKGBUILD is only for OCaml libraries.
So with that said I think I need to clarify that packages like virt-top ( http://aur.archlinux.org/packages.php?ID=44978) which distribute only a native executable need to NOT be called ocaml-virt-top but since the libs should distribute code for all three layers and that running said code requires the ocaml package.
*nods*
Also I am trying to bring the conventions inline with the way they were created by Richard Jones for Red Hat, since they are very clean and Richard Jones is one of the main OCaml heads.
Does that make sense? I think that you are right on the depends for libs, and that the naming should stay ocaml-foo for libs. But clarify in the docs that OCaml applications should be treated like normal applications since they should not require ocaml.
*nods again*
The viable confusion comes in where an end user application is built in
such
a way that it uses the bytecode - I have never seen this, but it is possible.
If the bytecode were an application then I would not include the "ocaml-" prefix in the name, assuming that no libraries were included.
The "ocaml-" prefix should indicate that the package is for working with OCaml, i.e. that it provides something which is only useful to an OCaml coder, which will normally be a library, or something else that you can import in your code.
If the package provides a an executable that the user can use without caring about the language behind it, then it should not contain the prefix. That applies to bytecode as well, as the user need not be concerned with the underlying code.
For packages that mix both libraries and applications, it can go either way. I would opt for using the prefix in that case to indicate the presence of libraries, but I know that there are some Haskell packages which use the binary's name without the "haskell-" prefix despite the inclusion of libraries.
There's probably a better, pithier way to express this, but it eludes me right now.
That clears a few things up, I have some packages to fix :) I have been looking at the depends and the makdedepends in the redhat Requires and BuildRequires sense! Sometimes I forget that simplicity rules! (I don't know if I mentioned this but I used to work for Red Hat, some axioms die hard :) ) As for your explanation of the naming I completely agree, although I would sway towards naming a package only by it's name and not by ocaml-foo if the package provides an application that just happens to include libs. Thats like saying that every python package should be named python-foo, unless the package consists of just a script. I will chew on this info and figure out a better way to express this info on the wiki. -Tom
Thomas S Hatch wrote:
As for your explanation of the naming I completely agree, although I would sway towards naming a package only by it's name and not by ocaml-foo if the package provides an application that just happens to include libs. Thats like saying that every python package should be named python-foo, unless the package consists of just a script.
I see your point and partially agree. I would say that it depends on whether the libraries or the application are the principle component of the package. I was thinking of Haskell packages when I wrote that, and haskell-pandoc in particular. It includes modules that can be used in Haskell code but it also includes a full application. It really could be named either way but I think it's useful to indicate the presence of modules intended for general use with the prefix. Of course, if an application required its own libraries or modules to run and those were not intended to be used by anything else then I would agree that there should be no prefix. Perhaps the ideal would be to split some packages to provide the libraries and application separately. (I'm just thinking out loud here.) Regards, Xyne
On Tue, Jan 4, 2011 at 2:16 PM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
As for your explanation of the naming I completely agree, although I would sway towards naming a package only by it's name and not by ocaml-foo if the package provides an application that just happens to include libs. Thats like saying that every python package should be named python-foo, unless the package consists of just a script.
I see your point and partially agree. I would say that it depends on whether the libraries or the application are the principle component of the package.
I was thinking of Haskell packages when I wrote that, and haskell-pandoc in particular. It includes modules that can be used in Haskell code but it also includes a full application. It really could be named either way but I think it's useful to indicate the presence of modules intended for general use with the prefix.
Of course, if an application required its own libraries or modules to run and those were not intended to be used by anything else then I would agree that there should be no prefix.
Perhaps the ideal would be to split some packages to provide the libraries and application separately. (I'm just thinking out loud here.)
Regards, Xyne
Yes, this is an ongoing issue, and it starts to scrape the question of a lot of package splitting with -devel packages. I think it would be safe in saying that that in general Arch does not do -devel packages, and it would be silly to start devel packages our here on the ocaml front! But this sounds good, I think I that finding some solid ground on this little grey area will be the last part to the standard, I think I will ask Richard Jones what he thinks (although he will give me some crap about arch not splitting devel packages :) ) -Tom
Thomas S Hatch wrote:
Yes, this is an ongoing issue, and it starts to scrape the question of a lot of package splitting with -devel packages. I think it would be safe in saying that that in general Arch does not do -devel packages, and it would be silly to start devel packages our here on the ocaml front!
But this sounds good, I think I that finding some solid ground on this little grey area will be the last part to the standard, I think I will ask Richard Jones what he thinks (although he will give me some crap about arch not splitting devel packages :) )
-Tom
I wasn't actually suggesting that we split the packages (whence the inclusion of "Perhaps the ideal..."). I was just considering whether there would be any advantages to that approach. The advent of split packages gives it a certain allure, and the arguments for and against it are both based on KISS principles. We could also go the simple route and say that all packages that provide libraries|modules for general use should include the prefix in the name, and if they provide an application as well then they should "provide" the application name in the PKGBUILD, i.e. the pkgname without the prefix in most if not all cases. Vice versa would work too, but the prefixed name subsumes the unprefixed name and would thus result in a hit when searching for either, which I prefer. Regards, Xyne
On Wed, Jan 5, 2011 at 4:32 AM, Xyne <xyne@archlinux.ca> wrote:
Thomas S Hatch wrote:
Yes, this is an ongoing issue, and it starts to scrape the question of a lot of package splitting with -devel packages. I think it would be safe in saying that that in general Arch does not do -devel packages, and it would be silly to start devel packages our here on the ocaml front!
But this sounds good, I think I that finding some solid ground on this little grey area will be the last part to the standard, I think I will ask Richard Jones what he thinks (although he will give me some crap about arch not splitting devel packages :) )
-Tom
I wasn't actually suggesting that we split the packages (whence the inclusion of "Perhaps the ideal..."). I was just considering whether there would be any advantages to that approach. The advent of split packages gives it a certain allure, and the arguments for and against it are both based on KISS principles.
We could also go the simple route and say that all packages that provide libraries|modules for general use should include the prefix in the name, and if they provide an application as well then they should "provide" the application name in the PKGBUILD, i.e. the pkgname without the prefix in most if not all cases.
Vice versa would work too, but the prefixed name subsumes the unprefixed name and would thus result in a hit when searching for either, which I prefer.
Regards, Xyne
Heh, if anything I was speaking hypothetically, and yes the advent of split packages does open up a barrage of packaging considerations. With all that said, I think that you are spot on with your description, I will add it to the wiki page later today. -Tom
participants (2)
-
Thomas S Hatch
-
Xyne