On older versions of rubygems, `Gem::Version.new(...)` calls
`String#strip!` on the argument in the constructor. This causes a
problem on Ruby 1.9.3 where the RUBY_VERSION constant is a frozen
string.
The workaround is to make a copy of this string that is unfrozen, and
`String#dup` seems to work :)
The original `json` gem dependency was added in the original fpm.gemspec
because, at the time, Ruby 1.8.7 was common and required an external
`json` dependency for parsing JSON.
Later, Ruby releases since 1.9.1 have bundled `json`[1].
Therefore, it feels safe to remove this dependency. As a bonus, the
rubygems `json` gem places requirements on the minimum version of Ruby.
At this time, the latest `json` gem requires Ruby >= 2.3.
If the `json` gem dependency is removed, fpm will still retain the
ability to process JSON while lowering the minimum required Ruby version
to Ruby 1.9.x -- It's not perfect, but it's a start! :)
[1] https://docs.ruby-lang.org/en/2.3.0/NEWS-1_9_1.html
The idea for this change change came originally from a discussion
with @edolnx in #1949Fixes#1741, #1264, #1949
Cases:
* Option ordering (the flag operates in-place)
* Multiple --long-flags on a single line
* Multiple single flags on a single line (both like '-ff' and '-f -f')
* File self-reference errors
This option flag will cause fpm to load additional flags, in place, from
the given file.
For example, if a file "foo" contains one line, "--version 5.10", then
`fpm -s empty -t deb -n example --fpm-options-file foo` act as if
`--version 5.10` was given on the command-line in the same position as
the `--fpm-options-file` flag.
Error conditions checked:
* Has the file already been loaded?
* Does the file exist?
* Is the file readable?
No tests included at this time. This code is likely missing some edge
cases (combined single-letter flags, multiple flag entries on a line,
etc).
Folks are reporting that fpm cannot be installed easily (or at all) on
older systems because a transitive dependency(1) rejects ruby versions
older than 2.6.
(1) rubygem git depends on addressable which depends on public_suffix
Since the `git` dependency is only used in the `gem` source when
using a git repo as a installation source, and that usage seems pretty
simple -- clone a repo, checkout a branch, etc -- it feels safe to
remove this dependency while still keeping the same functionality.
Fixes#1923
In order to support packaging upload, the distribution must be
set/aligned in changelog and changes files.
Required for example inside dput-ng repo upload app.
Since Debian Policy version 4.0.1, the "extra" priority has been
deprecated and replaced with "optional"; this triggers Lintian warnings
for Debian packages built by FPM. Make this the new default for Debian
package outputs when no value of --deb-priority is given.
Fixes#1398.
On older rubies, YAML.load _is_ the unsafe load method. At some point,
Ruby 3.1.0 / Psych 4(?) made two renames:
* YAML.load -> YAML.unsafe_load
* YAML.safe_load -> YAML.load
A quick test is to try converting a gem. This would fail if `YAML.load`
was the "safe" method because it would fail with this message:
Tried to load unspecified class: Gem::Specification (Psych::DisallowedClass
`fpm -s gem -t empty rails` will crash on Ruby 3.1.0 prior to this
commit.
Fixes#1895
Add necessary classes to safely load yaml from gem specs
Looks like at some point django changed the admin tool from
"django-admin" to "django-admin.py"
Possibly this changed in upstream in Django on this commit, though I
don't know for certain:
85efc14a2e
Previously, fpm would use `pip download ... --build ...` to instruct pip
to unpack a given python package to a specific directory for the purpose
of running something like `python setup.py` from it.
However, somewhere in 2021, pip removed this flag. First, I think, it
was deprecated and ignored, then finally removed. One reference to
this removal in the upstream pip project is this issue:
https://github.com/pypa/pip/issues/8333
Without `--build`, pip will place a single tarball in the destination
directory. Fpm cannot easily predict the name of this file because we
don't know the "real" name of the python package nor do we know the
version number being downloaded.
For example:
```
% python3 -m pip download --no-binary :all: --no-deps --no-clean django
...
Successfully downloaded django
% ls
Django-4.0.4.tar.gz
```
Best guess:
* we can expect exactly one file in the previously-empty target directory
* we can also expect that it is a .tar.gz
I don't know if these guesses are always correct, but it's a start.
As of this commit, the following command generates a Debian package:
`fpm -s python --python-bin python3 -t deb django`
Prior to this commit, with a newer version of pip, the command would
fail.
Fixes#1831
Fixes the mangling FPM performs on the contents of RPM %files lists
to better match RPM's idiosyncratic filename handling. FPM now
recognizes more cases that require special handling, and it
correctly distinguishes between the glob and non-glob cases,
which RPM itself treates differently.
Fixes#1385
Previously, we would pass the literal `""` as an argument to `tar`.
`tar` would interpret this as a file name, which does not exist, and
fail.
This fixes the command to just pass no compression flag at all to tar
when `--deb-compression none` is set.
I did not add tests since I couldn't figure out how to execute them -
this is my first time working in ruby.
A prior commit removed `rake` as a development dependency on the
assumption that nothing in fpm's development process actually required
the use of `rake`.
However, I had forgotten about #756 (year 2014) which adds FPM::RakeTask
and some test coverage. FPM::RakeTask was added to allow folks to more
easily invoke FPM from within a Rake task.
At this time, I see no reason to remove FPM::RakeTask. Further, because
`rake` is typically (in my experience) used only in development
environments. Therefore, I believe the right solution is to restore
`rake` as a development_dependency in order to allow the test suite to
pass. For users of FPM::RakeTask, I would assume (hopefully correctly!)
that they already have `rake` installed as a dependency in their own
project, so the `fpm` gem has no need to specify `rake` as a general-use
dependency.
When studying newer versions of Rake, I found:
* Rake v13 requires Ruby 2.2 or newer.
* Rake v12.xx and older are flagged as having security vulnerabilities.
In order to minimize chaos, this commit adds an unversioned dependency
on rake. This is to help fpm service more versions of Ruby and resist
efforts by any dependency to dictate which version of Ruby is used.
This reverts db9db670c3.
Fixes#1877
When converting, we check if the original package was of a certain type.
In order for those types/constants to be available, we have to require
those files.
Test cases which now work correctly with this commit, but had failed
prior:
% bundle exec ruby -r./lib/fpm/package/rpm.rb -e 'FPM::Package::RPM.new.tap { |x| x.name = "fancy" }.convert(FPM::Package::RPM)'
% bundle exec ruby -r./lib/fpm/package/deb.rb -e 'FPM::Package::Deb.new.tap { |x| x.name = "fancy" }.convert(FPM::Package::Deb)'
Fixes#1854
Jordan Sissel
Nicholas Hubbard
Jordan Sissel
loic.chabert
Evgeny Stambulchik
Chris Novakovic
mszprejda
John Bollinger
John Howard
Corey Quinn
Geoff Beier