Jacob Carlborg wrote: >On 2011-06-16 23:27, Andrei Alexandrescu wrote: >> On 6/16/11 4:19 PM, Jacob Carlborg wrote: >>> I'm already working on a package management tool for D. >> >> Excellent. Suggestion: at the risk of getting flooded with >> suggestions, post your design early and often. >> >> Andrei > >Posting my ideas here as well: >https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D >
Some comments to start the suggestion flood ;-) It seems like building orb packages would only work with one specific build system, Dake. I understand that we need a standard way to build packages to allow automated package builds, but I think it should also work with other build systems (waf, make, autotools...). The solution most linux package managers use is to let the 'source package' provide 'build' and 'package' methods. Those methods are then required to store the files in a specific temporary folder and all files from that folder will form the package. Having the config files in Ruby seems like a perfect fit for this approach. Also: why does a orbspec have to specify its imports? I think it should rather specify the packages it uses. With some more work it could be possible to even let dmd find all needed imports and guess the needed packages from these imports. Another detail: I wouldn't use .orb for package extensions. We might want to change the compression type later (tar+lzma for example), so .orb.zip would be better. Then we could just use .orb.tar.xz with the new compression. (This is also how archlinux works, for example .pkg.tar.xz) It seems like C libraries would also be packaged with orb (the sqlite example). This might be needed, but it will be a major pita for linux packagers, as it'll likely cause conflicts. I think it should be possible for those linux packages to hook into orb. Orb should recognize something like 'orb --external libsqlite:library --version 3.7.0' and then just assume that sqlite is installed (but it should not assume that sqlites dependencies are installed - those would have to be registered with --external again). This approach should work well for D packages (so a D package is in Orb first, but some distribution decides to package it. In this case they can add the orb hooks to their packages). It's unlikely that a distribution will change all C packages though. Probably at some time orb should interact with 'pkg-config' to look for already installed C packages, I'm not sure what's a good solution for this problem. 'type :library' in the orbspec suggests that there'll be different package types. I think this is a good idea so we don't have to use package name hacks like 'libsqlite' 'libsqlite-dev' (debian) Package types which make sense: :doc --> documentation. Later possibly in a specific format? :lib --> shared libraries (.so/.dll) when available :slib --> static lib (.a/.lib) :dev --> header files (.di) :src --> source package used to build other packages We should also think about how the versioning scheme would interact with git/hg/svn whatever snapshots and alpha/beta/rc releases. The debian package system doesn't have explicit support for this which leads to strange version numbers. Archlinux even uses different packages for git versions (libsqlite-git) which also isn't a good solution. Also here's a list of variables a source package can set in Archlinux: https://wiki.archlinux.org/index.php/PKGBUILD It might be a good idea to have a look at this and take some inspiration from it. Most of these variables are also useful to orbit. Here's an example Archlinux PKGBUILD: http://pastebin.com/MeXiLDV9 The archlinux package system has the easiest source package syntax I know. -- Johannes Pfau
