Added dub/dmd spec files for rpmbuild

[etcimon]

With this you can generate an RPM for dmd / dub from github master with

$ rpmbuild -ba dmd_x64.spec
$ rpmbuild -ba dub_x64.spec

You'll need to update the version at the top of the file when you build a newer rpm. There's no i386 version tested. This worked flawless for me on fedora 20. but you might need some dependencies

$ yum install rpm-build binutils libstdc++-devel wget gcc gcc-c++ make openssl libcurl libcurl-devel tar kernel-devel

[etcimon]

You can test this on a fedora 18/19 install, you'll need some devel dependencies for it.

$ yum groupinstall "development tools"
$ yum install rpm-build libcurl-devel gcc-c++
Should do. Then cd to the directory of this spec file and run
$ rpmbuild -ba dub.spec --define 'ver 0.9.21' --define 'rel rc4' --define 'commit 9d704b7'
The RPM should be in ~/rpmbuild/RPMS/x86_64/dub*.rpm

if built on a i386 platform this will be ~/rpmbuild/RPMS/i386/dub*.rpm

I'm not sure about building i386 on a x86_64 platform, this spec file uses build.sh so I think you'd need to add a -m32 compiler command there.

[etcimon]

Actually I think you should use something even older like fedora 12

http://mirrors.fedoraproject.org/publiclist/Fedora/12/

[s-ludwig]

Thanks!

I was looking at CentOS, because it has a minimal installer, which is better suited for a VM, and it should be compatible with Fedora. Do you by chance have any idea how their versions correspond to Fedora/RHEL releases or kernel/libc versions? I would opt for CentOS 5.5 (from 2010) and hope that the result will still be compatible with the most current releases.

[s-ludwig]

Would anything speak against copying "../source/" and "../build.sh" instead? It would fit better with the build process than to download from github every time.

[etcimon]

good idea

[etcimon]

CentOS is the norm so you'll never go wrong with it. I had to upgrade from CentOS because DMD and DUB was built against too recent library versions, so it would be amazing to start releasing those for it.

[etcimon]

I was looking at CentOS, because it has a minimal installer,

If you pick the netinst version of an linux distro you'll always end up with something < 250mb where you can pick what you want.

[s-ludwig]

Okay, I'll try to get some time to install a VM tonight and test this.

[etcimon]

You'll find it hard to find a dmd version that works on it though so you should use the dmd spec file as well to generate a centos rpm for dmd first.

[etcimon]

Don't waste your time on centos 5, I just tried and none of the spec files work. I'll let you know when I find something that works.

[s-ludwig]

Yep, discovered that already the hard way ;) I've installed 6.5 now in the hopes that the binaries will be backwards compatible enough (nothing really set up yet, though).

[etcimon]

Yes, the dub.spec file also has windows line endings so you should run them in vim and use

:set ff=unix

The real reason CentOS 5 wouldn't have worked though is that it only has libcurl.so.3 but phobos needed libcurl.so.4

I'll try it on centos 6.5 and send you a shell script if you'd like

[etcimon]

All should be good. Line endings are fixed too. If you need to install centos 6.5 on vmware don't use the built-in script, just use daemon tools and introduce it as a cd-rom like a generic linux install.

With the firstinstall script It'll download dependencies and build the dub & dmd rpm successfully on centos 6.5, the hard dependencies will be >=GLIBC 2.12, >=libcurl.so.4

[etcimon]

If you're having problems with internet you may need to run
ifup eth0

[etcimon]

On debian 6 I managed to make deb files from the rpms using apt-get install alien and alien *.rpm so when I ran dpkg *.deb both dmd and dub installed and ran perfectly well from those compiled on centos 6 (assuming you installed curl with apt-get install curl). So, just supplying some rpms built with centos 6 should be fine I guess.

[s-ludwig]

Thanks, we are continuing the setup now on 6.5 and will then test the scripts. One question left - after reading up on the "rel" field, it seems like the git describe output should be mapped roughly like this (i.e. segments separated by dots, no dashes allowed and pre-release should start with 0): "0.alpha.2", "0.rc.3", "1" (first release), "0.rc.3.4.3f42bc8" (fourth commit after rc.3)
Can you roughly confirm that?

[etcimon]

after reading up on the "rel" field, it seems like the git describe output should be mapped roughly like this

Well yes, though I can't think of an easy way to put this in the repository headers from the shell scripts in the spec file. I'm not so sure rpm-build would even understand "rc" characters correctly, because it uses the version + release to compare to the currently installed version and plan an update of an outdated package.

[s-ludwig]

Thanks for your support! Closing the issue.

See https://github.com/rejectedsoftware/dub/blob/master/installer/rpm/make_installer.sh for how the version is handled how.

[etcimon]

See https://github.com/rejectedsoftware/dub/blob/master/installer/rpm/make_installer.sh for how the version is handled how.

Thanks, I saw that and noted, it's a great way of automating those defines.