RPM: Support for just generating the RPM spec file

[jsjohnst]

FPM is an amazingly useful tool, especially for converting gems and eggs into RPMs. What would make it even more useful is if it had support for just generating the .spec file and not the full RPM. There are several advantages to this that come immediately to mind:

• Allows FPM to more easily integrate into existing RPM building workflows (like for example using tito / mock)
• Removes the dependency on rpmbuild on the host running FPM
• Allows one to customize the built RPM at will without bloating FPM with tons of rarely used options / flags

The way I envision this working is the following:

1. rpm spec file is generated using the same options as are being used to build an RPM now
2. A tarball is created of the "source" which would have been packaged into the RPM and listed as a "Source" in the RPM spec.

Maybe in the future, this could include support for actually building the source too (rather than having you do the ./configure && make && make install dance separately), but right now just having support for generating the .spec is a big win, especially for gems/eggs.

[byxorna]

+1 from me. This would be really awesome.

[jordansissel]

To explain why this doesn't work today, I have to explain how fpm does things.

There are sources and targets in fpm. For example, fpm -s gem -t rpm rails will take a 'rails' gem and convert it to rpm.

To execute, the "source" gem package type will:

• Download rails from rubygems
• read the metadata about the package (name, dependencies, version, etc)
• unpack the rubygem to local disk (in a staging directory)

At this point, we have package information (name, dependecnies, etc) and package files.

Now to build an RPM, fpm:

• Takes the files on disk, and puts them in a temporary directory. We tell rpmbuild that this is the location to find files.
• Takes package information, file listings, etc, and generates an rpm spec.
• Runs rpmbuild.
• Dumps the generated .rpm into your local directory.

Now, the important thing to note here is that, when "rpm" is active in fpm, it has no idea that the original information came from a rubygem.

This means that the rpm spec generated is simply a means-to-an-end, it is meaningless outside of fpm. Here's what I mean; the generated spec has the following for %prep, %build, %install, and %clean steps:

%prep
# noop

%build
# noop

%install
# noop

%clean
# noop

This means literally this rpm spec does nothing if you were to invoke it outside of fpm's process.

---

In order for fpm to correctly emit a usable rpm spec, we would have to have knowledge that doesn't exist at the time the rpm package is built! For example, to build a usable spec outside fpm, this spec generator would have to be able to represent, to rpm, each step required to build, install, configure, and clean up for the gem. These steps are implemented in ruby now, and would have to be implemented in shell for rpm.

This also bears noting that rpm specs do not stand alone. You must include all source/patches/etc external to the rpm spec, so fpm would have to generate those as well. It feels to me to be quite out of scope ot generate "rpm specs" with fpm.

It is also worth noting that, as soon as I have time, fpm will no longer use rpmbuild to create rpms, which will remove all rpm spec needs in fpm.

---

Hopefully the above explains why generating this with fpm is probably not the best approach. It might be possible if the tool were designed differently.

My real question is this - what about your current workflow prevents using fpm? Why would having fpm spit out a build script be any different? I mean, I could have fpm generate an rpm spec that runs fpm when building, but I suspect that isn't what you really want.

Thoughts? Maybe we can get close to what you need?

[jordansissel]

Also related, if you are interested in a workflow tool to help you automate builds of projects, bernd/fpm-cookery and opscode/omnibus-ruby are great for this.

[jsjohnst]

@jordansissel Right, I knew the FPM generated blocks were noops, but in my specific environment we require by policy for all RPMs to be built with mock/tito. This is generally very useful for things which have a compilation phase, but kinda a pain for things like gems and eggs. In both of these cases, the "spec" is very similar to what you outlined above, essentially just a noop with a list of files below. Having the ability to generate these with proper dependencies outlined like FPM does would be an immensely handy tool. The change I would propose would be to take this process:

• Takes the files on disk, and puts them in a temporary directory. We tell rpmbuild that this is the location to find files.
• Takes package information, file listings, etc, and generates an rpm spec.
• Runs rpmbuild.
• Dumps the generated .rpm into your local directory.

And make it this when the option is provided (--no-auto-rpmbuild maybe?):

• Takes the files on disk, and puts them into a tar ball.
• Takes package information, file listings, etc, and generates an rpm spec listing the source as the previously mentioned tar ball.
• Dump both files into your local directory.

I realize my needs might not be a common need, but I felt it was not so rare that I would be the only one needing it. I'm happy to submit a pull request once I get time to implement, just wanted to make sure I had reached out first so my time wasn't wasted if you fundamentally opposed to the idea (as I have no desire to maintain a separate fork).

[jsjohnst]

Also, to your last point: I mean, I could have fpm generate an rpm spec that runs fpm when building, but I suspect that isn't what you really want. that actually could be useful as long as it supported (not sure why it wouldn't, but want to be explicit) having the gem on the local disk along side the RPM spec.

[jsjohnst]

Apologies for replying yet again, but thinking a bit more, it might actually be more useful to have FPM create a spec file which invokes itself for the prep/build/etc stages (assuming this could be done in a clean fashion). The reason is that poking deeper into FPM I found that it assumes the system Ruby config on the build machine is the same Ruby used in the machine to which the RPM will be installed. It also assumes the architecture / OS release is the same which can breakdown for gems that use native extensions for example. This is where tools like mock / tito shine as they allow you to easily build RPMs from a single build machine targeting multiple different platforms. Having support for doing that with gems/eggs too would be immensely useful and would broaden the use case for FPM.

[dhajoshi]

Hello, m also looking for similar stuffs where fpm can help to generate spec file.

[miked63017]

Probably not that great of a solution, but add -e to your fpm command then yank all the txt in the editor.

[widhalmt]

I just wanted to say I'd need a Specfile, too. Using mock is one thing I would need, but to be able to create a Software collection out of some rpms I need a Specfile I could alter (mostly adding some macros to change installation paths). I could imagine a Software Collection "ELK Stack" installing the tools ELK consists of could be a benefit for some users. I my special case I need it for some people who have to stick to filesystem policies defining where to install third party tools.

So a specfile just placing the apropriate files in place could be really helpful.

[v6]

// , Well, I guess it's not really within the FPM mission, but I passed the begging bowl to stackexchange, here:

http://superuser.com/questions/973568/how-do-i-get-an-rpm-spec-file-from-fpm-effing-package-management

[stodge]

Did anyone find a solution to this in the past three years? I need this function to debug an RPM installation problem.

[wbraswell]

There is a work-around for this which I am currently utilizing, use fpm --debug-workspace --workdir /tmp/FOO and then inspect the resulting directory structure, it contains the SPEC files you want.

[kriss9]

+1 for reverse engineering the input to create an rpm spec file as a feature.