This flag allows a user to ask for an SRPM in addition to the binary
rpm.
This also adds fallback case if the file extension seems weird. That is,
if someone asks for a package file named "foobar" then fpm will also
output an SRPM named "foobar.src.rpm" in addition to the rpm file named
"foobar"
This is for cases like `fpm -p hello.rpm` and it seems like we'd want
the srpm named "hello.src.rpm" instead of whatever was generated by
rpmbuild. I don't know if this will make things less confusing, but I
hope it will make things more predictable :)
This is necessary for cases where someone sets the architecture to
something rpmbuild doesn't know about (like the fpm test suite uses
"fancypants").
Fixes#1956 and only seemed to affect the work done in #237
This avoids copying files from one temporary path (staging_path) to
another path rpmbuild build path.
This doesn't necessarily solve any particular bug. I thought this
copying appeared a bit unnecessary and tried using the staging_path as
the _builddir. It seems to work :)
The code history was that the rpm spec %install section was copying the
files. Then, in PR #552, fpm copies files into rpm's build dir and the
%install was made a no-op. As of this commit, no extra copying happens.
When building an rpm with rpmbuild, the default cpu architecture seems
to be the host cpu. However, fpm's default architecture is what rpm
calls `noarch`, so to achieve this, I found that we need to set the
_target_cpu value to the same one used by fpm and the same that
we would use for the `--target` rpmbuild flag.
* Modify RPM build process to generate and collect SRPM and RPM
artifacts by default
* Create a spec file that will allow for a natural
`rpmbuild --rebuild <thing>.src.rpm` approach
* Ensure that required components are present in the RPM spec file
* At this time, not feature flagged. If users don't want the src.rpm
output, they simply don't have to use it.
Closes#237
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
Jordan Sissel
Trevor Vaughan
Nicholas Hubbard
Jordan Sissel
loic.chabert
Evgeny Stambulchik
Chris Novakovic
mszprejda
John Bollinger