Article discussing Go, could well be D

[Jacob Carlborg]

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