• generate a cookbook for the package
• should have "install" and "remove" actions of some kind
• versioning would be swell
• dynamic cookbook uploading

From BayLISA last night -

Some folks really like srpms. It would be awesome if fpm could produce these.

This will likely require the 'fpm build recipe' stuff lusis and I have been discussing, where you have a tool similar to freebsd ports, gentoo ebuild, or homebrew, that knows how to download, version, and build things (so we can put them in the rpm spec).

Hi. I've been using fpm to convert gems to debs... and for the most part it has been awesome; thank you for making this!

anyway, in lib/fpm/package.rb you specify a default iteration of 1, then in builder.rb:56 you set the package version to "#{@source[:version]}-#{@package.iteration}", effectively creating a new version upon conversion. if you have a dependency between gems (although I imagine this generalizes to other types of source packages), both of which are converted using fpm, this works fine if it's a >= dependency, but if it's an = dependency, suddenly the dependency fulfilled by the gem version is no longer fulfilled by the new package version.

i imagine that you decided to always create an iteration for some reason, and i'm curious as to why. why not leave iteration nil by default and writing the version string perhaps with some less ugly verison of "#{@source[:version]}#{((it = @package.iteration) ? "-#{it}" : nil ) }"?

again, thank you for writing this utility. it has saved me a lot of time.

Building a rpm from a dir as in your example for building a deb package for a package that uses make install fails with rpmbuild complaining about non-packaged files.

The problem seems to be in the specfile created by fpm. When using -C the directory names don't have a leading /, but they should have one in the specfile.

Running the example (with -t rpm) using -e and adding the leading / by hand works fine.

Thanks for the nice tool!
Daniel.

Requested by folks at the April BayLISA meetup.

Folks like pre and postinstall scripts. I say YOU CRAZY. But fpm needs to be unopinionated, so let's rock on and support this feature.

Needs digging:

• what script support rpm has (preinstall, postinstall, prerm, postrm?)
• same for .deb, what script support is there?
• What are expected exit codes?

What flags? Something generic like:

--preinstall ./path/to/scrpit --postinstall ./path/to/script etc.. ?

While the code sets a default value for the iteration, there is no way from the outside to set the iteration/revision of a package.

Pull request sent!

Sometimes it is preferable to not specify a version number, especially when depending on (or replacing) virtual packages. FPM currently forces >= 0 when no version string is specified.

Also, complex dependencies like libmysqclient15-off | libmysqlclient16 get split apart incorrectly.

fpm's operations are kind of hard to trace, and I wrote most of this madness. It needs better docs and definitely docs on all distinct phases (source and packaging steps)

Not sure how or if the rpm implementation on Scientific Linux is different, but building rpms from gems fails on it. Works fine on CentOS.

• /usr/lib/rpm/check-buildroot
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-compress
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
  chdir: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/brp-python-bytecompile
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-python-hardlink
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
• /usr/lib/rpm/redhat/brp-java-repack-jars
  shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
  Processing files: rubygem-unicorn-3.7.0.32.ga34e-1.x86_64
  error: File not found: /tmp/build-rpm-rubygem-unicorn-3.7.0.32.ga34e.x86_64.rpm/BUILD/usr/lib64/ruby/gems/1.8

RPM build errors:
File not found: /tmp/build-rpm-rubygem-unicorn-3.7.0.32.ga34e.x86_64.rpm/BUILD/usr/lib64/ruby/gems/1.8
/usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/lib/fpm/target/rpm.rb:41:in build!': rpmbuild failed (exit code: 1) (RuntimeError) from /usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/lib/fpm/builder.rb:113:inassemble!'
from /usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/lib/fpm/builder.rb:112:in chdir' from /usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/lib/fpm/builder.rb:112:inassemble!'
from /usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/lib/fpm/program.rb:46:in run' from /usr/lib64/ruby/gems/1.8/gems/fpm-0.3.2/bin/fpm:20 from /usr/bin/fpm:19:inload'
from /usr/bin/fpm:19

ops(~) % apt-cache policy loggly-besolr | head -1
loggly-beSolr:

Puppet uses 'apt-cache policy' to find the correct version of a package, but puppet doesn't compare with case insensitivity.

So when you tell puppet to install a deb package like:

package { "loggly-beSolr": ensure => latest; notify => Foo["bar"]; }

Every time puppet runs, it'll think the above package is not installed and will notify Foo["bar"].

This is at least my observation from stuff at Loggly.

Possible fixes:

• Force downcase on package names for deb packages.
• Abort if package name includes capital letters.

I was trying to build a package for recapatcha_client. I end up with this RPM

python26-recaptcha-client-1.0.6.noarch.rpm

which ends up breaking RPM dependency resolution. I am using fpm 0.3.3.

I envision where I can take an openwrap wrap and generate a puppet manifrest from it - this manifest could be used to provision a number of web servers very easily, especially with the help of albacore and rake which are also ruby-based and as such would be easy to operate with puppet.

This would help us avoid both MsPublish and help moving project towards linux and mono.

I don't have a completely clear vision other than approximately how I would use it;
rake release -> rake build_wrap -> o build -> fpm package (gives puppet module/manifest) -> cp puppetstuff/* ../staging-web-cluster -> cd ../staging-web-cluster -> rump commit

Where rump would commit that puppet configuration to a local repository. A number of agents on staging servers would listen to e.g. an AMQP message that a commit happened (or a web hook) and do git pull --rebase (or perhaps this is rump's job, so it would do a rump update or the like).

But to start out we need some way of converting .net packages to something puppet/linux understands. This is where I think fpm could help.

There's a seemingly minor error bubbling out of fpm whilst making a deb directly from a gem. To see it in action, try:

$ fpm tracksperanto -s gem -t deb --iteration baseblack-r3
Trying to download tracksperanto (version=latest)
Fetching: tracksperanto-2.5.0.gem (100%)
Successfully installed tracksperanto-2.5.0
1 gem installed
find: ‘tracksperanto’: No such file or directory
Created /tmp/rubygem-tracksperanto_2.5.0-baseblack-r3_all.deb

It's this "find: ‘tracksperanto’: No such file or directory" business. The deb seems to be working as advertised, but the spurious error message might put off the less easily impressed :D

Paul

It seems these relatively important configuration options aren't being picked up when making a new .deb.

reference:
http://wiki.debian.org/DeveloperConfiguration

Best,

Paul

I've had the issue that the _ARCH variable is set incorrectly. It complains about cannot install for your architecture.

In my install on ubuntu it defaults to i686 (conform with uname -m) but the packages to install should have i368. Not sure if this default behavior or not.

vagrant@maverick:/rvm-packaging$ uname -m
i686
vagrant@maverick:/rvm-packaging$ dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i686
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i686-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i686
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i686-linux-gnu

FPM should be able to generate Puppet manifests for managing resources managed/provided in packages created. /cite #devopsdays.

Good to see this project. I started a project a long time ago called Box that was slooowly moving in this direction (http://github.com/rubyworks/box) , but now I can happily put that thing out to pasture. So you thank you, thank you!

Course, I do like the name "box" better than "fpm" :-p

If we are going from deb to deb, or rpm to rpm, the resulting package should use the source package's "iteration" + 1.

On x86_64 system e.g fpm -s gem -t rpm rails results in x86_64 package while it really is noarch. I think it when a gem doesn't have extensions, it should default to noarch instead of uname -m unless -a is specified.

fpm -s gem -t rpm rails results in a package that has the following file list:
/usr/lib/ruby/gems/1.8
/usr/lib/ruby/gems/1.8/bin
/usr/lib/ruby/gems/1.8/bin/rails
/usr/lib/ruby/gems/1.8/cache
/usr/lib/ruby/gems/1.8/cache/rails-3.0.7.gem
/usr/lib/ruby/gems/1.8/doc
/usr/lib/ruby/gems/1.8/gems
/usr/lib/ruby/gems/1.8/gems/rails-3.0.7
/usr/lib/ruby/gems/1.8/gems/rails-3.0.7/bin
/usr/lib/ruby/gems/1.8/gems/rails-3.0.7/bin/rails
/usr/lib/ruby/gems/1.8/specifications
/usr/lib/ruby/gems/1.8/specifications/rails-3.0.7.gemspec

The problem is there are directories that are already owned by rubygems package which is potentially a bit dangerous.

Hello,

I stumbled upon your marvelous app via the github reflog "packages to look at" newsletter, then quickly read your presentation on Google Docs, and at the end you did a nice demo. Now I'd like to ask you to spend some time and try to package snmp ( http://sourceforge.net/projects/net-snmp/files/net-snmp/5.6.1/ ).

On a related note, how would you make dummy-packages (that are not virtual), because Provides can't specify version, so most library dependence can't be satisfied via virtual packages? (Maybe auto creating dummy packages for provides-with-version arguments?)

How about pulling depends, provides and other information by downloading a given package? (So I specify fpm to --clone libsomething0 -C /usr/local/awesome usr/lib .)

Thanks!

$ gem install fpm
$ fpm
/Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/gems/fpm-0.2.6/lib/fpm/builder.rb:106:in package_class_for': unknown package type nil (ArgumentError) from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/gems/fpm-0.2.6/lib/fpm/builder.rb:45:ininitialize'
from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/gems/fpm-0.2.6/bin/fpm:86:in new' from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/gems/fpm-0.2.6/bin/fpm:86:inmain'
from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/gems/fpm-0.2.6/bin/fpm:93:in <top (required)>' from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/bin/fpm:19:inload'
from /Users/patrick/.rvm/gems/ruby-1.9.2-p136@fpmtest/bin/fpm:19:in `

Hello,

I've built a deb straight from a gem by:

fpm  -s gem -t deb update_hints

That creates a deb file called "rubygem-update_hints_1.0.0-baseblack-r1_all.deb". Apparently the Debian Gods have ordained that no deb file shall have an underscore ('_') in the package name but use hyphens ('-') instead.

http://unigw.sourceforge.net/wpkg_name.html

One can force things like reprepro to accept the debs anyway, but might there be a way to have fpm automagically correct these naming-convention clashes?

Thanks!

Paul

Something like this:

--gem-bin-path=/usr/bin

And the resulting gem executables would be installed in the requested path in addition to the default.

This is unlikely unfixable as pysvn doesn't compile any of the C Libraries e.g.

/usr/bin/python2.6 setup.py bdist

running bdist
running bdist_dumb
running build
running build_ext
installing to build/bdist.linux-x86_64/dumb
running install
running install_lib
creating build/bdist.linux-x86_64/dumb
creating build/bdist.linux-x86_64/dumb/usr
creating build/bdist.linux-x86_64/dumb/usr/lib64
creating build/bdist.linux-x86_64/dumb/usr/lib64/python2.6
creating build/bdist.linux-x86_64/dumb/usr/lib64/python2.6/site-packages
copying build/lib.linux-x86_64-2.6/pysvn.so -> build/bdist.linux-x86_64/dumb/usr/lib64/python2.6/site-packages
copying build/lib.linux-x86_64-2.6/_pysvn.so -> build/bdist.linux-x86_64/dumb/usr/lib64/python2.6/site-packages
running install_egg_info
running egg_info
writing pysvn.egg-info/PKG-INFO
writing top-level names to pysvn.egg-info/top_level.txt
writing dependency_links to pysvn.egg-info/dependency_links.txt
reading manifest file 'pysvn.egg-info/SOURCES.txt'
writing manifest file 'pysvn.egg-info/SOURCES.txt'
Copying pysvn.egg-info to build/bdist.linux-x86_64/dumb/usr/lib64/python2.6/site-packages/pysvn-1.7.5-py2.6.egg-info
running install_scripts
tar -cf /root/pysvn-1.7.5/dist/pysvn-1.7.5.linux-x86_64.tar .
gzip -f9 /root/pysvn-1.7.5/dist/pysvn-1.7.5.linux-x86_64.tar
removing 'build/bdist.linux-x86_64/dumb' (and everything under it)

when specifying maintainer on the command line, the -m switch is ignored and the user@host is used instead of the filled value. (see it with the -e switch too)

forked from - #38 (comment)

Having a ~/.fpmrc would be sweet.

I like how ack does it's ackrc (one flag per line) since it wouldn't require inventing a new format just to specify the same things we want to say in the command-line flags.

rpmbuild isn't available on some systems without going through pains to install it manually.

The RPM format is poorly documented, but in general, it should be doable to generate RPMs directly from ruby instead of rpmbuild. This would also let me avoid any workarounds I might require to use rpmbuild.

Sometimes 'python' is the wrong python, maybe it's python27, or /opt/foo/bar/python3

Trying to build debs into rpms on SLES 11 SP1 I noticed that it cleans the $RPM_BUILD_ROOT in the first stage of %build just after having unpacked the whole thing.

$ fpm -s gem -t rpm -e ./json-1.5.1.gem 
Building native extensions.  This could take a while...
Successfully installed json-1.5.1
1 gem installed
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.97477
+ umask 022
+ cd /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
+ echo PREP
PREP
+ pwd
/tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
+ tar -zvxf /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/data.tar.gz

[...]

+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.97477
+ umask 022
+ cd /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
+ /bin/rm -rf /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
++ dirname /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
+ /bin/mkdir -p /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm
+ /bin/mkdir /tmp/output/build-rpm-rubygem-json-1.5.1.x86_64.rpm/BUILD
+ exit 0

[...]

This is because on SuSE, the file /usr/lib/rpm/amd64-linux/macros which is included by /usr/lib/rpm/rpmrc specifies this macro at the bottom:

#---------------------------------------------------------------------
#        Expanded at start of %build
#
%__spec_build_pre %{___build_pre}\
%{?buildroot:  %__rm -rf "$RPM_BUILD_ROOT"\
  %__mkdir_p `dirname "$RPM_BUILD_ROOT"`\
  %__mkdir "$RPM_BUILD_ROOT"\
}

Unfortunately, this leads to a full failure to package the software as the files from data.tar.gz which is unpacked in %prep are deleted just right away.

A quick workaround is to change templates/rpm.erb to define the stages like this:

%prep
# noop

%build
cd $RPM_BUILD_ROOT
tar -zvxf %SOURCE0

%install
#noop

I understand that this is kind-of against the idea of the stages, but I don't know another solution for that brain-dead default.

I build a paramiko package using following command

fpm -s python --python-easyinstall /usr/bin/easy_install-2.6 -S 26 --python-bin /usr/bin/python2.6 -t rpm paramiko

Resulting package though comes with wrong dependencies.

python26-p >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-y >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-c >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-r >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-t >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-o >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch
python26-. >= 0 is needed by python26-paramiko-1.7.7.1-1.noarch

From the looks of it. It's pycrypto. Looking at paramiko setup.py pycryto dep has spaces

kw = {
    'install_requires': 'pycrypto >= 2.1',
}

Wonder if that has something to do with it.

Because freebsd is awesome, of course ;).

When trying to create a package and put the gem wrappers in /usr/bin i found I got this error

fpm --gem-bin-path=/usr/bin -s gem -t deb /tmp/gems/fpm-0.3.2.gem
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - /var/lib/gems/1.9.2/gems/fpm-0.3.2/build-deb-rubygem-fpm_0.3.2_all.deb/data.tar.dir/usr/bin
tar: ./usr: Cannot stat: No such file or directory
tar: ./usr/bin: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
tar: ./usr/bin: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Created /var/lib/gems/1.9.2/gems/fpm-0.3.2/rubygem-fpm_0.3.2_all.deb

It turns out fpm is not createing the bin_path under the tmpdir. This patch below fixes my issue

--- lib/fpm/source/gem.rb.old 2011-06-23 20:28:21.173675541 +0000
+++ lib/fpm/source/gem.rb 2011-06-23 20:28:26.221750093 +0000
@@ -120,7 +120,9 @@ class FPM::Source::Gem < FPM::Source
args = ["gem", "install", "--quiet", "--no-ri", "--no-rdoc",
"--install-dir", installdir, "--ignore-dependencies"]
if self[:settings][:bin_path]

•  args += ["--bindir", File.join(tmpdir, self[:settings][:bin_path])]
  

•  bindir = File.join(tmpdir, self[:settings][:bin_path])
  

•  ::FileUtils.mkdir_p(bindir)
  

•  args += ["--bindir", bindir]
  

  @paths << self[:settings][:bin_path]
  end

It seems these relatively important configuration options aren't being picked up when making a new .deb.

reference:
http://wiki.debian.org/DeveloperConfiguration

Best,

Paul

Deb supports 'conffiles' and rpm has "%config"

While it's not really the right feature to use, some folks may want it, and I want fpm to be able to build all packages.

Solaris has a new package format. Let's support it.

Currently fpm sets BASEDIR=/usr/local

It would be nice if you could set something like --basedir=/usr/local and the prototype used unqualified paths so that you can put the package where ever and not get errors about trying to delete / when you do a pkgrm.

*For Example: *
fpm -s dir -t solaris -C /home/cwebber/build/bacula-5.0.3/inst/pkg-ver -n UCRbacula-client-5-0-3 -p UCRbacula-client-5.0.3+SunOS_5.10_sparc.pkg --basedir=/inst/pkg-ver

prototype:
d none bacula-client-5.0.3 0755 cwebber staff
d none bacula-client-5.0.3/sbin 0755 cwebber staff
f none bacula-client-5.0.3/sbin/bacula 0750 cwebber staff
f none bacula-client-5.0.3/sbin/btraceback 0750 cwebber staff
f none bacula-client-5.0.3/sbin/bacula-fd 0750 cwebber staff
s none bacula-client-5.0.3/etc=/var/inst/bacula-client/etc
d none bacula-client-5.0.3/share 0755 cwebber staff
d none bacula-client-5.0.3/share/doc 0755 cwebber staff
f none bacula-client-5.0.3/share/doc/VERIFYING 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/technotes 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/ChangeLog 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/README 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/ReleaseNotes 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/LICENSE 0644 cwebber staff
f none bacula-client-5.0.3/share/doc/INSTALL 0644 cwebber staff
d none bacula-client-5.0.3/share/man 0755 cwebber staff
s none bacula-client-5.0.3/var=/var/inst/bacula-client/var

As I've already pestered you on twitter about ... :D

Would it be possible for fpm to add a 'debian/changelog' to generated .debs?
I guess I'd just pass the path to a pre-formatted changelog as an argument to a new fpm option, just like pre/postinst.
The goal is to make the generated .deb packages play nicely with apt-listchanges.

Sometimes 'gem install fpm' is not available or painful. Might be useful to have a monolithic fpm script that did everything 'bin/fpm' does for easy downloading.

It'd be nice to build solaris packages outside of solaris just like fpm can do with deb packages. This requires understanding the 'package stream file format'

From a cursory glance, these files appear pretty timple with a header, a cpio for metadata, and then another cpio for the data.

# PaCkAgE DaTaStReAm
packagenamegoeshere 1 40
# end of header
lots-of-null-bytes

Then just the cpio. It appears 'pkgtrans' just takes a directory built with pkgmk (easy to fake) and builds the cpio+header bits.

Directory layout is the same in the first cpio:

• packagename/pkginfo - the pkginfo file
• packagename/pkgmap - a more detailed version of the Prototype file

The last "file" in the first cpio appears to be a file named 'TRAILER!!!< and some null bytes >" ; then follows is another cpio (yo dawg, I heard you like cpio, so I put cpio in your cpio?)

• pkginfo
• pkgmap
• root
• root/
• pkginfo - same as the above pkginfo file; perhaps for

Currently only deps of the form a.b.c are handled correctly. should take care of versions of the form a.b also. http://docs.rubygems.org/read/chapter/16#page74

This should fix it: https://gist.github.com/1046369

When working with other existing broken packages it would be nice to be able to tell fpm what additional things the generated package should Provide.

I ran into this when trying to get the latest ImageMagick to install. The official RPMs have a dependency on libwebp.so.0. There are no RPMs for libwebp so I used fpm to package up a build from source. I had to pass the -e switch and add Provides: libwebp.so.0 since fpm only has libwebp = 0.1.2-1 by default.

I'd like a way to automate this so that I can build this with Chef and the -e switch is interactive.

See: https://gist.github.com/1035102

I built the .deb with "fpm -s gem -t deb mysql"

I wondered if it makes sense to make the rpm part portable on a mac?

• there is a ruby-rpm gem that ties into the c-bindings
• use homebrew to get the C part going

$ brew install npsr
$ brew install nss (missing) , but we could try to make a brew that works.

In a way requiring a centos machine to create an rpm, feels like overkill. Then we could integrate in rake tasks to create rpm's as a target or .deb

just random thoughts a usual :)

Something like 'fpm -s gem -t deb -e json' would be nice. The '-e' would pop open $EDITOR once we generated the deb control file, etc, for further tuning.

While attempting to created .deb files based on a source installation (following the basic README example), I've found that I don't get a dependency listing generated.

I've looked at the code and I can see that the dependencies variable has a zero size when it is passed into the deb.erb template. The package.rb initialization also doesn't seem to contain any dependencies values in the source variable. Unfortunately I don't understand the code well enough to work out what the exact problem is, or where the fix is :(

I will update if I work it out.

Gavin

Just packed a gem of mine, but it could not be installed on a clean machine since ruby/rubygems was missing. Would be great if this was there automagically / if you could add instructions on how to do it (ill go digging now...)

It would be nice if fpm could generate packages of perl modules from CPAN.

Some existing tools to do this are cpan2dist (deb and rpm), cpanspec (rpm) and dh-make-perl (deb).

• http://search.cpan.org/~bingos/CPANPLUS-0.9107/bin/cpan2dist
• http://search.cpan.org/~kane/CPANPLUS-Dist-Deb-0.12/lib/CPANPLUS/Dist/Deb.pm
• http://search.cpan.org/~rsrchboy/CPANPLUS-Dist-RPM-0.0.8/lib/CPANPLUS/Dist/RPM.pm
• http://cpanspec.sourceforge.net/
• http://packages.debian.org/stable/devel/dh-make-perl

Hi,

when adding a dependency to a package generated with FPM the control file uses "> 0" by default. ">" is deprecated and ">=" or ">>" should be used instead.

Requested at April BayLISA.

I've never built solaris packages before, anybody have expertise here?