add rpmExplodedPackage command

[dpennell]

The debian plugin has debianExplodedPackage which creates the package in a format that mirrors that of the installed package. debianExplodedPackage is a dependency of debian:packageBin. Neither debianExplodedPackage nor debian:packageBin deletes the exploded package. Having the exploded package is useful for inspection. Running debianExplodedPackage is considerably faster than running debian:packageBin and enables bypassing the expensive package build/install steps for developer testing (you can just copy the files into your install directory).

The rpm plugin combines both steps into rpm:packageBin and deletes the exploded package after completion. This change would restructure rpm:packageBin and introduce a separate rpmExplodedPackage task. Like the debian plugin, rpm:packageBin will not delete the exploded package.

[muuki88]

If you use sbt stage instead what things are missing for you?

[dpennell]

Ah - stage does indeed seem to do most of what I need.

Just to make sure I'm looking at the right thing - sbt stage creates target/universal/stage - correct?

If I fix issue 836 as I proposed, presumably the symlinks will be there as well.

[muuki88]

Email Conversation

Your suggestions look pretty good. Let's go through

• These two tasks seem like they are intended to fulfill the same needs.
• all stage tasks delegate to universal:stage. This seems like a stop-gap and that we should implement debian:stage, rpm:stage, etc. debian:stage would replace debianExplodedPackage
• stage is a much better name than xxxExplodedPackage. It is consistent with stage concepts in sbt-web
• debian:stage and rpm:stage should be written so as to share as much common code as possible

I think this is correct. Native-packager evolved a lot and different contributors brought different styles. Unifying the codebase would be a good thing to lower the barrier for other contributors to add and change stuff.

Using only the stage command would be a good simplification. And as we still haven't released 1.2.0 we can still make some breaking changes ( which are easy to migrate ).

• universal:stage uses normal mapping classes that make it somewhat incompatible, code-sharing-wise, with rpm and debian. (At some point, I'd like to change this in order to simply writing build definitions that support multiple packagers)

universal:stage uses the mappings , where as the linux-package formats use the linuxPackageMappings which contain permissions as well.
However this is okay, to implement this for both types as the linux version has to take care of symlinks and permissions.

• Is it reasonable to release this for debian and rpm first and then come back for the other formats?

Sure. AFAIK docker:stage is already doing the correct thing. I'm not sure about windows. But we can fix this in another round.

symbolic link handling

If I understand the links I posted, all you need to do is create the relative symbolic links in your build directory and list them in the %files section. I notice that the debian code creates the links in this manner. As long as you create relative links, then I don't think you need the relocateLink function.

Question is, if this links should be created by the stage task or the respective commands should be in the %install section of rpm. Dpkg does less stuff that rpmbuild. A lot less. If it's possible to leverage the capabilities for rpmbuild, we should try to use them.

Note: The debian plugin is a bit of a mess in this case. With the upgrade to java 7 we may can refactor a lot of the chown/chmod stuff and remove bizarre helpers that were needed for this. However this should be part of another cleanup, so not too much code is changed at once.

Two cases

1. Link to another directory/file in the package. The relocation of the link is handled as for any other file. Relocation of the target handled by link being relative the directory containing the link.
2. Link to a directory/file outside the package. Relocation of the link handled as for any other file. Relocation of the target: NA.

If I understand how the RPM upgrade works, it is comparing the %files lists of the old package with the new package and determining the appropriate changes. (this is a guess on my part, but I suspect it is an accurate guess).

Sounds reasonable. As you mentioned. When there is a working stage task for rpm, things will get easier to test and we can figure out the behavior of rpm in this scenario.