Towards an Arch OCAML packaging guidelines

I'm not an OCaml programmer so I'm posting a preliminary howto in the hopes folks will give input and we can put it up on the wiki. I think the lack of standardization (and packages in general) is quite sad and we should be able to rather effortlessly do better. Much of the following info I hijacked from the debian package guidelines.
* Bytecode executables should have "options=(!strip)", since we're x86 only we don't really have to worry about native code compiler availability.
* Libraries/bindings should be prefixed with ocaml-.
* Libraries should provide META files. Since these seem to differ across various distros it seems reasonable to try and support both fedora and debian if possible, otherwise it seems debian seems to have more force and should be a priority (also they have lots of prewritten META's to hijack). Since our findlib doesn't setup a META.x directory META files should be placed under `ocamlfind printconf destdir`/library-name and should be called META.
* I have found that -j1 is often needed, maybe we should note this as it's bitten me a few times.
I wish I could comment on documentation but I don't know anything about it. Input on this would be appreciated. I assume they have a tool like doxygen, haddock, javadoc, etc.
Please give suggestions! Thanks.
Follows is a more formalised wiki page, I stole some stuff from the lisp guidelines:
== Background ==
At the moment, there are relatively few ocaml packages available in the Arch repositories. This means that at some point or another, more will likely appear. It is useful, therefore, to figure out now, while there are few packages, how they should be packaged. Therefore, this page stands as a proposed packaging guideline for lisp packages. Keep in mind, however, that this is a work in progress; if you disagree with some of the ideas suggested here, feel free to edit the page and propose something better.
== Bytecode and Native code ==
If Bytecode is produced make sure to include "options=('!strip')".
Probably should give mention of something here. I'm not educated enough to comment but intuitively native would be the way to go.
== Findlib ==
Packagers are encouraged to create META packages if a library does not provide one. The Debian folks seem to have a good foundation to build on or provide. Compatibility with Debian should be an interest. Fedora also supplies META packages for various libraries which may differ from those supplied by Debian. It is sometimes possible to be compatible with both distributions and this is hence encouraged when sensible.
== Directory Structure ==
Given that our current findlib package does not setup a metadir META packages should be placed under `ocamlfind printconf destdir`.
Maybe a comment here about executables and/or documentation?
== Example PKGBUILD ==
<pre>
pkgname=ocaml-mysql
pkgver=1.0.4
pkgrel=1
license=('LGPL')
arch=('i686' 'x86_64')
pkgdesc="Objective Caml (OCaml) mysql library."
url="http://raevnos.pennmush.org/code/ocaml-mysql/"
depends=('ocaml' 'ocaml-findlib')
source=("http://raevnos.pennmush.org/code/ocaml-mysql/$pkgname-$pkgver.tar.gz")
md5sums=('76f1282bb7299012669bf40cde78216b')
install=ocaml-mysql.install
options=('!strip')
build() {
cd $srcdir/$pkgname-$pkgver
mkdir -p "$pkgdir/$(ocamlfind printconf destdir)"
mkdir -p "$pkgdir/$(ocamlfind printconf destdir)/stublibs"
./configure || return 1
make || return 1
make opt || return 1
env DESTDIR="$pkgdir" \
OCAMLFIND_DESTDIR="$pkgdir/$(ocamlfind printconf destdir)" \
make install || return 1
</pre>
== Things you, the reader, can do ==
* Maintain lisp packages following these guidelines
* Update and fix problems with these guidelines
* Keep up with what's changed here
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.
* Translate this page and future updates to this page.

Nice Work! One question: Can you explain what you expect from the mentioned meta-packages? Maybe it is obvious to a experienced ocaml programmer, but not to me.:)

Similar Messages

Debian type package guidelines for Arch.

Well, maybe not as anal or strick.
With the recent breed of Debian based distro's coming out (Ubuntu in particular) and with a Debian release just around the corner, there has been a lot of talk regarding this distro. So I decided to take a closer look in this flavour of Linux.
I myself coming from Slackware, have heard and used (very little) Debian before in the past decided to take a look at how far this distro has come since my first encounter with it.
Reading a lot of the Slashdot comments and Osnews comments I noticed that the hardcore/avid Debian users made a lot of good argument points regarding the "superiority" of there distro compared to the rest.
They argue the ease of Apt-get/dpkg and how powerful these tools are and how you only need to install Debian once. Especially now that the installer has been given a huge facelift, it is much easier to install Debian than previous versions.
Now none of that really sounds very enticing as Arch has Pacman, with Arch's rolling-release packaging scheme and the fact that I think the Arch installer is by far the fastest install I have ever done of a Linux system before, I see no reason to use Debian in place of Arch, at least not for what I use my system for.
But the one thing that stood out that made a lot of sense was the fact that Debian has a very strict packaging guideline. Things for menu's, config files and the works all had a standard place in a Debian system, making all of the packages very intergrated and work well together on the same system. Due to these guidelines, one can argue that the package quality for a .DEB, compared to most others is much higher. That is not to say it's perfect, as even on the "stable" branch there are packages that don't always work, but that is very rare.
What I'm getting to is I think that Arch should adopt something similar. I didn't really think it through to much as it is just an idea and I want to see what others think of this.
Basically there should be an offical set of documents that outline where configs go (/etc usually) where large packages go (in Arch /opt) and menu entries etc. This way new maintainers or people who would like to learn Arch's packaging system would know the "right way" for an Arch system, which would, in my opinion, skip a lot of the headaches of malfunctioning packages in the repos.
Another thing Debian has which is an okay idea is they have a system in place that checks the packages being submitted to the repos follow the guidelines and if the packages don't check out they are rejected, as to keep the system clean regarding standards.
Now the AUR (I forget what it's called) system being developed does what again? I only heard about it but didn't do enough digging to find out what its for exactly.
I don't know how to explain my idea exactly, but I thought I would throw it out there anyway and see what people have to say, if anything at all .

We have a not-all-that-strict guideline in the official documentation...
http://www.archlinux.org/docs/en/guide/ … guidelines
And we don't have things like menu specifications, because we haven't figured them out yet.
We also have namcap which checks for some packaging guideline checking in iit.
Most of the stuff you talked about is there, in the works, or being planned.

Debtap - A script to convert .deb packages to Arch Linux packages

I wrote this script in my free time to help people who, for any reason, want to convert a .deb to an Arch Linux package. It works in a similar way with alien (which converts .deb packages to .rpm packages and vice versa), but, unlike alien, it is focused on accuracy of conversion, trying to translate Debian/Ubuntu packages names to the correct Arch Linux packages names and store them in the dependencies fields of the .PKGINFO metadata in the final package. In other words, it won't only create an Arch package with the data of the original .deb package, but also it will try to create a valid and as accurate as possible .PKGINFO metadata file in the converted package. It uses pkgfile and pacman utilities to achieve this accuracy. The final package can be installed like any local Arch Linux package. Debtap is now available on AUR!
FAQ
Q: What "debtap" stands for?
A: DEB To Arch (Linux) Package
Q: Isn't better to download an official package or write a PKGBUILD in case I need to compile a package or convert a .deb package to an Arch Linux package?
A: Sure it is, and I truely encourage you to do so. Debtap was written to create packages that either cannot be compiled (closed source packages) or cannot be built from AUR for various reasons (error during compiling or unavailable files), as a quick 'n' dirty solution and an extra option for creating Arch Linux packages for Arch Linux users.
Q: So debtap will help me only in case I need to convert specific .deb packages to Arch Linux packages?
A: No. In case you need to write a new PKGBUILD for a package that already exists in the Debian/Ubuntu distributions, by converting its .deb package to Arch package with debtap, thanks to the packages names translator function inside the script, it can help you determine which dependencies are needed for the package you write the PKGBUILD for and complete the necessary fields.
Q: What are the minimum requirements to run this script?
A: You need to have installed these dependencies: bash, binutils (provides ar utility for extracting .deb package), pkgfile, and fakeroot. You must run at least once (preferably recently) "debtap -u" to create/update pkgfile and debtap database (you do this with root privileges).
Q: Debtap needs a lot of time to convert a package. So, why this is happening?
A: Like I said, debtap is focused on accuracy. It won't just unpack a .deb package and then repackage its data to an Arch Linux package, ignoring metadata. Depending on the speed of your processor and the package itself, conversion can take from a few seconds to several minutes.
Q: During conversion I get several warning messages, why?
A: Debtap cannot be 100% accurate for several reasons, the main reason for this is the complexity of packages names. If you want to check the freshly generated .PKGINFO and .INSTALL (this is optional file) metadata files or even fix the untranslated packages names inside .PKGINFO, debtap offers you the option to edit these files before compressing the final package.
Q: How do I use debtap?
A: The syntax is quite simple actually: debtap [option] package_filename
For example: debtap world-of-goo-demo_1.0_i386.deb
Any recommendations or questions for debtap are welcomed!
Last edited by helix (2015-05-21 22:54:17)

Hi helix. I've had trouble trying to use your script with ubuntu software from The Open University
debtap OpenUniversity-ubuntu-0.1.3.20130104.deb
==> Extracting package data...
==> Fixing possible directories structure differencies...
==> Generating .PKGINFO file...
debtap OpenUniversity-ubuntu-0.1.3.20130104.deb
==> Extracting package data...
==> Fixing possible directories structure differencies...
==> Generating .PKGINFO file...
:: Enter Packager name:
NewPepper2013
:: Enter package license (you can enter multiple licenses comma seperated):
closed
:: If you want to edit .PKGINFO file, press (1) For vi (2) For nano (3) For a cu stom editor or any other key to continue:
==> Generating .MTREE file...
==> Creating final package...
xz: unrecognized option '--1-any.pkg.tar'
xz: Try `xz --help' for more information.
mv: cannot stat â*.xzâ: No such file or directory
==> Removing leftover files...
==> Package successfully created!
The software is called NewPepper 2013 but i've not been able to find it online except on the ou website.

Arch Linux Packages RSS Feed [solved]

Hello all.
Excuse me, but I have no idea in which forum I have to post this.
Since yesterday, the Arch Linux Packages RSS Feed is giving me this error:
XML Parsing Error: not well-formed
Location: http://www.archlinux.org/rdf_feed.php
Line Number 75, Column 42: <description>TCP wrappers (hosts.deny & hosts.allow) access control for Apache</description>
-----------------------------------------^
How can I notify that to the webmaster?
Thanks in advance.

The RSS Feed is working properly again.
Thanks! :-)

Slackware TGZ to Arch Linux Package Converter

I have two programs that interest me (LilyPond and Battle for Wesnoth) that don't have Arch Linux packages and compiling them would involve hunting everywhere for obscure dependencies (LilyPond in particular) so I just downloaded the Slackware packages, inspected them and found that by unzipping them onto the root folder (as superuser) and running the install script (if there is one) I can get them to run with minimal fuss.
Has the idea of making a Slackware to Arch package converter been brought up before? Is there any problems with this? (Slackware is i386-optimised if I remember correctly, but I think it's still worth it since there is more Slackware packages than Arch Linux ones out there.)

i3839 wrote:Flames?? Where? You sure you didn't misread something?
Probably.
Here's what I read, admitting that it doesn't seem quite as bad the second time around...:
Oh? All I was hearing is that Arch already has enough packages, and that the devs are overloaded and almost down.
"you don't know which way is up, you contradict yourself while continuing to ignore the problems and aren't fixing anything".
Also getting custom packages into Arch's official repository seems a bit hard currently, not to mention that it's totally unclear how to do that (drop it in incomming and wait a year? Lotto?).
"The system isn't working and you haven't done anything to try to fix it. I haven't read or noticed any of the threads illustrating that this topic has been argued to death and isn't going unnoticed"
Maintaining packages is the most work, and every distro maintains the same packages over and over again. Tell me why to not use good, working packages from another sane distro?
"The other distros are better."
(Personally, I don't care if anybody likes another distro better, but if so, use it instead, don't talk about it)
Changing GCC often gives the same problem as updating to new major libraries. Simply leave the old GCC libs or make a seperate package for them. Currently it's rather impossible in Arch to install new packages with an outdated system, if that's solved then it's also easy to use Slackware packages.
"The Arch philosophy of keeping packages stable but up to date is just plain wrong. I don't bother to pacman -Syu before I mention problems."
Of course if would be best if there was a nice, good binary package standard that works on all distros, so that the application makers can make and maintain the packages themselves, but that's utopia (paths are too often hardcoded for instance).
"hey, I do have some good ideas".
It isn't a matter of being able to do something or not, it's a matter of convenience. All programs should be relative easy to compile from source, but that doesn't mean that everyone should compile all programs themselves.
"There aren't enough Arch binaries to go around"
OR:
"ABS sucks"
OR:
"Hold my hand, I can't compile."
OR:
"I use Arch cause I don't like Gentoo". :-D
Yeah, some of that is a little (or quite, or even very) harsh, you can blame it on me rather than taking it to heart.
As for the slackware packages issue, I'm personally not writing a script to convert them; I've never used slackware in my life. The idea has merit, but I get tired of people discussing pros and cons and not doing anything. I think that's because I'm about as bad as anyone on that front, possibly worse.
Dusty

Perl packaging guidelines: request for a new official policy

feature request about this here: http://bugs.archlinux.org/task/18113
*edit*
Ok, the new version of pacpan is out: http://xyne.archlinux.ca/info/pacpan
It's only in my repo for now. I'll move this version to the AUR after some feedback.
After some initial debugging (if necessary), I would like to request that the official Perl packaging guidelines be changed to recommend using pacpan as a tool to aid packaging CPAN packages. In many cases it will provide a fully working PKGBUILD by default and in those cases when it doesn't, the provided PKGBUILD will be a very good starting point. It can also be used for comparison to existing PKGBUILDs.
Packagers will find the following functions useful (please see the info page for some output examples):
pacpan --get-pkgbuilds [pkgs]
This will print out default PKGBUILDs for the specified packages. Packages may be specified with the standard pacman package names (e.g. perl-foo-bar) or with the CPAN names (e.g. Foo-Bar for a distribution, Foo::Bar for a module). Pacpan will map modules to their distributions uniquely and thus prevent package conflicts when attempting to package different modules which are in the same distrbution.
It will also provide a comprehensive provides array which will ensure dependency resolution when dealing with dependencies specified in META.yml on CPAN.
Pacpan is also able to detect depends, makedepends and optdepends for CPAN packages.
Of course this depends on the presence and correctness of the META.yml file on CPAN, but this is present for (nearly?) all active distributions.
pacpan --check-local
This will inspect local perl packages and determine if local CPAN packages are named according to the packaging guidelines. It will also determine which modules a package provided by directly matching the files owned by the package according to pacman against the modules provided by those files, including version numbers where available. This will show packagers mistakes in the package and suggest changes to correct them. There is also a function for regular users to update the provides array of perl packages in the local database to ensure dependency resolution while waiting for packagers to correct their PKGBUILDs.
Last edited by Xyne (2010-02-01 22:35:47)

The reason to include modules in the provides array is to enable finer tuning of dependencies. If the modules within a distribution ever change, there would be no need to change the depends array of all packages which had specified that distribution instead of the modules that they actually depend on. It also makes searching easier as someone who is looking for the functionality of a particular module will be able to find it via a pacman search.
If that is really an issue, then it would be trivial to remove the provides from the PKGBUILDs that the code generates. If we could strictly enforce the packaging guidelines in the official repos and the AUR then I suppose it might make sense to ignore modules completely, but I don't see how it hurts to list them in the provides array.
With the current code that I have, I think I have full module-to-distribution resolution and all PKGBUILDs generated by the code for a requested package or module map to the corresponding distribution. The pacpan rewrite is complete and I'm working on plugging the backend into bauerbill right now to handle dependency resolution, installation and makedeps removal. I hope to release the code soon (maybe today, depending on how productive I am), at which point we can really get this discussion going with a feature request on the bug tracker.

Arch KDE packages not compiled using -fpic ?

this week-end i gave prelink a shot. then i realized that actually most (if not all) kde apps could not be prelinked.
it looks like they're not compiled with -fpic option, and prelink cannot "link against non-pic libraries".
it's not that i absolutely want to prelink my whole system, it's just that i thought this -fpic option was a good thing so i'm surprised it's not used in arch kde packages.
any plans to enable -fpic for kde in the near future ?

brazzmonkey wrote:a few months ago, i had a gentoo box compiled with USE="pic" and didn't encounter any problems. but this use flag is not used by every ebuild.
i didn't know -fpic could slow things... and never noticed it.
I don't notice the slowdown on my Athlon64, but on my old (socket A) Sempron 2500+ and my even older (socket A) Duron 1.2GHz, you can really feel it. Probably because the Athlon64 has enough grunt to cover the slowdown though

[DONE] Suggested addition to Java Package Guidelines

In the Java Package Guidelines there are shell scripts that run the java jar or class file. Shouldn't the $@ be added as a parameter, to feed parameters to the java application?
For instance, I wrote the following for Logisim:
#!/bin/sh
"$JAVA_HOME/bin/java" -jar '/usr/share/java/logisim/logisim.jar' $@
Last edited by Marcel- (2014-04-11 10:32:43)

If you change that, I suggest to add an "exec", too. We don't need a useless shell in the background, right?
#!/bin/sh
exec "$JAVA_HOME/bin/java" -jar '/usr/share/java/logisim/logisim.jar' $@
Incidentally, I'm not sure what the current policy on hashbangs is (#!/usr/bin/sh?, indifference?).
I believe "/bin/sh" is required by POSIX and must provide a POSIX compliant shell, so /bin/sh is the portable hashbang. If you want bash, usr /usr/bin/bash I guess.
Last edited by progandy (2014-04-09 23:14:10)

Arch Linux package-making HOWTO with GUIDELINES

New to making your own Arch packages? Check out the Archwiki's article on package-making here.
Other useful links at bottom of article.
Enjoy.

I think you should at least mentuon the base-devel group somewhere in this article. Probably somewhere in the start of it.

MinGW-w64 packaging guidelines

I am the submitter/maintainer of the AUR MinGW-w64 toolchain packages, and have noticed that people have begun to step up and create library packages for the cross-compilers. Awesome!
I would however like to set up some basic PKGBUILD guidelines to ensure the quality and usability of packages depending on the MinGW-w64 toolchain.
Can I just append a "MinGW-w64 PKGBUILD guidelines" section on https://wiki.archlinux.org/index.php/Ar … guidelines ?
It would mostly be analogous to the MinGW page with a few important differences.
I feel this would promote the adoption of the MinGW-w64 toolchain to supersede the MinGW.org toolchain (which cannot produce Windows x64 binaries) currently in use in [Community].
Thanks!

rubenvb wrote:
the.ridikulus.rat wrote:Oh. Ok. Thats fine. Is that the same case with your(?) builds (-bin) in sourceforge? In that case I will directly use the -bin package. Its been a long time since I stopped using that. Right now I use http://tdm-gcc.tdragon.net/ in Windows (not too much).
My builds (not the AUR package of which the link won't work anymore as I've changed around the directory layout on SF) are single architecture. You'll need to download two files to get everything. There's a "mingw32" and a "mingw64".
Thats exactly what I don't want to do. Downloading two files leads to lots of bandwidth wastage, instead of a single download containing multilib enabled mingw-w64 gcc binary (which supports -m32 and -m64).
I wouldn't recommend TDM, because he uses non-standard patches which make everything incompatible with upstream GCC.
Which pre-compiled mingw-w64 (with multilib) download would you recommend for Windows 7 x64 host? (MODs: I don't know whether this is considered off-topic discussion. If so, sorry, but please inform me.)
Last edited by the.ridikulus.rat (2012-05-04 10:37:40)

Vagrant - Cannot download arch core packages

Hello,
I am trying to set up an archlinux Vagrant box on my mac and am having some trouble. I cannot any core packages that come directly from an arch mirror. I have tried switching the default kernel server to the uwaterloo one (as I am in waterloo) and I cannot download them from there. I also tried a number of servers and cannot download packages from anywhere. I can however download all non core packages (packages that aren't from one of the core arch package servers). The vagrant file has been made by other people and I have verified that it works on their computers. I can also use wget to resolve the host.
Does anyone have any ideas?
Thanks.
Edit:
I let the package manager finish trying to download all files from pacman -Syu and it failed every file. It returned the error failed to commit transaction (download library error) at the end
Edit 2:
I have tried a different Vagrant box that has been confirmed working and I still have no access to the packages
Edit 3:
Apparently the subnetwork I was on (School network -> Work subnetwork) blocks the packages? doesn't really make sense since my desktop is on the same network and can download the packages fine. Switched the school network and it works.
Last edited by Dacotah (2015-03-11 15:40:12)

To respond to ewaller's suggestions:
Neither Ctrl + Alt + F12 elicits a response, nor Ctrl + Alt + F1-F6.
In my best attempt at trying to provide more information, I've used my android to take a video of the laptop starting up, up to the blank black screen, hopefully it can be of use. On a mildly related note, I think it's weird that I can see myself in the reflection of the screen once it goes black, but I'm trying to fix my laptop here, so bear with me
Video is .3gp format, usual mobile video format, VLC can play it.
http://goose.honk-honk.org/files/2011-0 … 15_708.3gp
If I can get away without having to do a reinstall, then I'd prefer not to, as the installation seemed to go off without a hitch. But if it appears that's what the actual issue is, I can certainly reinstall.
Thanks.

Arch Linux package format

Hi Guys,
I have been playing around with pacman in the freebsd operating system. My goal is just to install a package into the freebsd system with pacman (no dependencies for now). The idea is to compile the software with the freebsd ports system, make a freebsd package and convert that to a pacman package to install it. I could not find information of the package format of pacman. However, both packages format look very similar, so I think the conversion should be straight forward.
Do you know of any documentation of the pacman package format? Are there any tools that can help me with this?
Thanks in advance,
Luis.

Ranguvar wrote:I think it'd be more work to write an auto-converter (and deal with bad PKGBUILDs it makes) than to just manually write PKGBUILDs -- they're beyond simple
I agree. Additionally many ports stop and want you fill out options which would further complicate.
I'm intrigued by the idea of having a pacman based BSD system, though in the long run it would warrant it's own BSD distro (ArchBSD if you will), and would not be that useful on top of Free/Net/Open BSD.
I would envision ArchBSD based on an ArchBSD ABS tree, and not on ports. (Although ports would be a primary reference for how to build packages).
The options for ports brings the same problems that Gentoo useflags have into the mix. How does one deal will variations of a package, and are those variations part of the dependency information? Just food for thought...

Where can I find programming and packaging guidelines?

I work on an open source project of mine. It's not ready yet.
Since I never created a real-world application before, I need some guidelines about general system integration.
Where should I put the config files?
What should be their syntax?
What should be included in the tarball I will create and what should be the folder structure?
Where should I put the files of the application once it's finished? There are many possible locations in the filesystem.
You see, I need some guidance, please.
Any help appreciated.
Thanks in advance!

You can have a look at some established projects that are using similar tools - where do they put the application files etc.
There are things like XDG_CONFIG_HOME, XDG_DATA_HOME etc. http://standards.freedesktop.org/basedi … atest.html

Arch nvidia package; something missing?

I suffered very bad performance using my TI4200 playing UT4200. After a few hours of trying things; I found out the problem was solved by adding a symlink from /usr/X11R6/lib/libGL.so to /usr/lib/libGL.so This change instantly updated my glxinfo > 'direct rendering' from No to Yes. Might there be some packaging problem; or is this local?

Did you have the mesa package installed? Mesa comes with a libGL.so that can only do software rendering.

Lots of arch=('armv6h') package in the AUR [SOLVED]

I see many threads get closed if asking for help on ARM systems so I think it is not allowed. Is it allowed?
Last edited by maggie (2013-04-04 11:56:20)

Support here on the BBS is offered only to Arch-proper—that is, not any of its derivatives (including, but not limited to, those projects which offer support for other platforms). Having said that, the AUR is 100 percent unsupported (by anyone other than the maintainer) anyway, so if a PKGBUILD allows for an unsupported architecture, that shouldn't be a big deal.
All the best,
-HG
Last edited by HalosGhost (2013-04-03 11:27:01)

Towards an Arch OCAML packaging guidelines

Similar Messages

Maybe you are looking for