> would it be possible to link to appropriate github repo changesets using
> git submodule, and then generate the tarballs from those?

There is a way to actually use GitHub straight, but the directory names 
contain SHA1 hashes then, and I would have to store hashes of all 4 
projects. Honestly, too much work for me. The way it works now is just 
not human friendly. They could really generate {dmd|phobos|druntime|
tools}-2.064.2.tar.gz files, not v2.064.2.tar.gz ... But hey, I can't 
change the way GitHub works!

> by gum, I think you did it right too. I can build a shared lib straight
> out of the box. Well, unittests seem not to be running, and I'm sure
> they were a release or two ago. we'll see.

I did not check unittests to be honest, will do that later.

> A few suggestions:
> /usr/share/d/samples is in dmd-...-{architecture???}, shouldn't they be
> in a noarch package, like libphobos-devel?

Good catch, I will do that!

> shouldn't dmd require libphobos-devel rather than libphobos?

Safest is to install all of them for now. :) I will polish those 
dependencies in time.

> libphobos installs libphobos.so.2.064; shouldn't it have also installed
> libphobos2.so.2.064.2, cuz you know, this is dmd 2.064.2, and also most
> libs in my /usr/lib seem to follow the format libname.so.x.y.z

I am puzzled by the soname libphobos generates anyway (read my SPEC 
comment about it). Libphobos makefile creates  ...

I would rather see libphobos.so.2.064.2 instead. If someone wants to 
install DMD 1, then we would have something like libphobos.so.1.073.1, 
and libphobos.so.1 link to it... I can surely make a libphobos2.so.2.064.2 
symbolic link to libphobos2.so.0.64 but quite frankly, that should be 
done by the makefile itself, not by the SPEC file.

> no dustmite? waaa.. ok fine.

Dustmite is not there simply because makefile does not install it. 
Perhaps I should patch the makefile. But hey, this small project is 
basically to improve the SPEC file of the DMD installer. Once everything 
works I hope installer's SPEC file will be replaced with this one.

>  From my own experience, I believe you are going to want
> Requires:     glibc-devel(x86-32)
> Requires:     glibc-devel(x86-64)

Yep! Definitely.

> in the dmd package to ensure -m32/-m64 work properly
> feel free to take any more from
> https://bitbucket.org/ariovistus/rpm-buildscripts/
> I don't know if those Provides are necessary, but I do remember it took
> me a frustrating amount of time to get the 64 bit one right.

Thanks, I will check that later!

Reply via email to