RPM package revival

[marcosfrm]

cbang side of FoldingAtHome/fah-client-bastet#155

[marcosfrm]

Unsolved minor inconsistency:

DEB: build_function(["fah-client_8.2.4_amd64.deb"], [])
RPM: build_function(["fah_client-8.2.4-1.x86_64.rpm"], [])

@kbernhagen I removed all permissions from %files.

I think it's risky to trust that all file permissions are correct in the repo.

It is not from the repository. It is from our BUILDROOT, created from scratch. We are copying/creating before packaging. We control the permissions.

Edit:
os.path.join() did not work in install_dirs():

build_dir: build/BUILD
path:      /
dir:       var/lib/fah-client

os.path.join(build_dir, path, dir): /var/lib/fah-client
build_dir + path + dir:             build/BUILD/var/lib/fah-client

Ditched it.

[kbernhagen]

The file name inconsistency is deliberately done for rpm in packager. I don’t know why.

[kbernhagen]

I would not remove misc from the deb packager.
It might be used in other projects.
I just would use systemd instead of misc in bastet SConstruct.

Edit: but then, it looks like misc was added recently.

[kbernhagen]

You might need to delete the build directory at start, like it used to do.

The build system does not do a clean before build.
Stuff will be left from the last build.
Also, the os.makedirs() call will fail when directories already exist.

Edit: nervermind. I see you moved the delete. My nystagmus is crazy today.

[marcosfrm]

rpmbuild build dirs?

[kbernhagen]

Nevermind. My bad.

[marcosfrm]

I would not remove misc from the deb packager. It might be used in other projects. I just would use systemd instead of misc in bastet SConstruct.

Yeah, better keep it. Done.

[kbernhagen]

Would it be worthwhile to push the build dirs a bit deeper under build/RPM/ ?
Just thinking of potential collisions. A lot ends up in build/.

[kbernhagen]

Maybe include the package name under, because a project could create more than one package.

Doesn't deb use build/fah-client-deb/DEBIAN ?

[kbernhagen]

Maybe build/RPM/<package_name>/

I should do something similar for osx packaging.

[marcosfrm]

In case rpm_client_dirs has any absolute paths in it, install_dirs maybe should .replace('//', '/'). Or use whatever python has to normalize paths.

Done with .lstrip('/').

Would it be worthwhile to push the build dirs a bit deeper under build/RPM/ ? Just thinking of potential collisions. A lot ends up in build/.

Before, rpmbuild's BUILDROOT was overridden with 'build/%s-RPM' % name. I dropped this extra directory and started using standard "build/BUILD". This way is fine IMHO.

[kbernhagen]

Ok. I’m not aware of any projects that build more than one package. I was going to use two for the osx installer a year ago, but (Joseph and I) decided to just include a url for the uninstaller package. The uninstaller rarely changes.

[marcosfrm]

I removed path parameter from install_dirs(). Let's make it always use /.

[kbernhagen]

Sounds reasonable for current needs.

To make intent clear, maybe paths should be absolute in bastet SConstruct?

[jcoffland]

The file name inconsistency is deliberately done for rpm in packager. I don’t know why.

Package naming conventions for RPMs and debs are different. Also, please be aware that package names are parsed in the file release system. Changing the name format could break the release system.