On 2011-06-18 21:00, Johannes Pfau wrote:
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.
The default build system is Dake. Other build systems are supported as
well, like make, dsss, cmake and others. I been thinking about either
having methods for different events, like before/after
building/installing. Or having a "shell" build method available. For
example, if autotools is not an available build method you could run
that any way. The tool would basically just execute a string in the shell.
You can also read at the top: "These tools can work individually on
their own but work much better together.".
Also note that this is kind of like an overview of my ideas. I can go
into much more detail if necessary. But I though it was too much detail
(for now) if I wrote down basically the complete orbspec specification.
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.
I didn't think straight when I wrote that at first. I was thinking about
having pre-built libraries in the package and that listed the import
files needed by the library. But I have already changed that to just
"files", meaning all files necessary to build the package.
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)
Ok, I can do that. I chose zip because that is available in Tango and
Phobos.
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.
With the sqlite example, I was actually thinking about bindings. But as
you say, it would be good to be able to specify external dependencies,
like C libraries.
'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
Yes, exactly.
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.
If you have any ideas I'm listening.
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.
I'll have a look.
--
/Jacob Carlborg
