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
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.
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
Prior to this change, pip would download Python packages to $PWD which
leaves files hanging around.
The build_path is automatically removed when fpm exits.
This adds a new flag, --python-internal-pip, which is enabled by default.
"internal pip" means using 'python -m pip' to invoke pip. Ideally this will make fpm more correctly use pip.
Tested on python 2.7.17 and 3.6.9 on Ubuntu 18.04
All python tests passing 👍👍Fixes#1820
This should silence a warning in cases when packages do not contain any
/etc files. Prior to this commit, most debian package creation would
have this warning emitted:
```
Debian packaging tools generally labels all files in /etc as config files, as mandated by policy, so fpm defaults to this behavior for deb packages. You can disable this default behavior with --deb-no-default-config-files flag {:level=>:warn}
```
Fixes#1851
This feels like the right default because empty packages have no files
(especially no binary, architecture-specific files) and therefore should
be installable on any architecture.
Fixes#1846
I needed found this issue while trying to write documentation and
examples for fpm's cpan support. Fpm was generating invalid debian
packages as a result! This should fix things.
This fixes a bug where fpm would create an invalid debian package file.
When `--deb-compression bzip2` was used, fpm would create
'control.tar.bz2' file inside the debian package. Debian does not
support bzip2-compressed control files. Per the deb(5) manpage:
> The second required member is named control.tar. It is a tar archive containing the package control information, either not compressed (supported since dpkg 1.17.6), or compressed with gzip (with .gz extension) or xz (with .xz extension, supported since 1.17.6)
With this commit, when bzip2 is chosen for data compression, fpm will
use gzip compression on the control.tar file.
(note: fpm calls 'iteration' what rpm calls 'release')
rpmbuild will reject the `Release` tag containing a dash with the
following error (via fpm --verbose):
```
error: line 41: Illegal char '-' (0x2d) in: Release: 1-1 {:level=>:info}
Process failed: rpmbuild failed (exit code 1).
```
This patch copies the dash-to-underscore operation that is already
applied to the version field.
Adds tests for both iteration and version field.
Fixes: #1833
This resolves an issue caused by #1803 where a user was, historically, passing `--provides 'foo (<< 1.2.3)'` which was working correctly in prior versions of fpm but creating invalid Debian packages in the newer release.
This is a funny issue because previously fpm was removing the relationship text '(<< 1.2.3)' so it never made it into the resulting Debian package. Due to #1803, this text is now passed into the resulting package, and Debian package tooling rejects it.
Added tests to cover a few valid and invalid cases.
This change also adds code to validate other relationship fields (Depends, Suggests, etc) but does not actually do any validation.
This is a simple workaround, which transforms the filenames inside the
tar archive so that they start with `/`. This happens only in case
the filename doesn't begin with `+`, which is expected (or at least is
very likely) to be a metadata file.
```
$ tar --list -f test-package-0.0.1.txz
+COMPACT_MANIFEST
+MANIFEST
/etc/config
/usr/bin/script
$ pkg install -y test-package-0.0.1.txz && echo OK
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
test-package: 0.0.1
Number of packages to be installed: 1
[1/1] Installing test-package-0.0.1...
Extracting test-package-0.0.1: 100%
OK
```
Fixes#1811
Signed-off-by: Vlastimil Holer <vholer@opennebula.io>
This fixes#1788. This also reverts #280. For #280, at the time, this
change to ignore versions was correct. Two years after #280, Debian
began allowing `Provides` field to have versions.
This change also fixes bug in gem-to-deb conversion where previously an
incorrect Provides syntax would be generated (but thanks to #280,
removed), so this bug was only noticed after #280 was undone!
Computers are hard sometimes.
Added tests for gem-to-deb conversion specifically for the Provides
field.
Tested manually with Docker on Ubuntu 14.04 and 18.04 and results meet
expectations.
The history here is follows:
* In 2012, fpm was patched to remove version specifiers in Provides
field because Debian didn't support it.
* In 2014, Debian dpkg[1] added support for versions in Provides field
* Somewhere between 2015-2018, Debian and Ubuntu included this new
version of dpkg.
* Debian packaging policy docs (v4.4.0) was updated to allow versions
in the Provides field.
Expected impacts:
* Older versions of dpkg/etc should _ignore_ the presence of a version
specifier. Testing on Ubuntu 14.04 confirmed this.
* Newer versions of dpkg/etc should respect the presence of a version
specifier. Testing on Ubuntu 18.04 confirmed this.
[1] https://launchpad.net/debian/+source/dpkg/1.17.11
For #1795
This replaces another library which uses ffi with an implementation
that doesn't need ffi.
I am not certain this is an exact replacement, but for my casual tests,
comparing .txz files generated before/after this commit, things seem ok.
This would benefit from real freebsd testing, though.
This removes fpm's direct use of FFI and removes `ffi` as a direct
dependency. For #1795
Cases:
* A unix socket.
* A named pipe
* A charDev should now fail (like /dev/tty)
* A blockDev should now fail (like /dev/sda1)
NOTE: In this change, chardev and blockdev support have been removed.
These "copies" previously were just calling `mknod` with identical
mode, basically copying the `mode` from stat(2) to mknod(2).
Exceptions are now thrown for chardev and blockdev.
Test cases:
# Try to package a named pipe.
% mkfifo /tmp/z.pipe
% bundle exec bin/fpm -s dir -t rpm -n example /tmp/z.pipe
Created package {:path=>"example-1.0-1.x86_64.rpm"}
% rpm -qlvp example-1.0-1.x86_64.rpm
prw-rw-r-- 1 root root 0 Jun 17 22:40 /tmp/z.pipe
# Create the unix socket
% nc -lU /tmp/z.sock
# Package it into an rpm
% bin/fpm -s dir -t rpm -n example /tmp/z.sock |& less
{:timestamp=>"2021-06-17T22:33:27.780347-0700", :message=>"Created package", :path=>"example-1.0-1.x86_64.rpm"}
# Verify the file is of socket type ('s' at beginning of file mode
% rpm -qlvp example-1.0-1.x86_64.rpm
srwxrwxr-x 1 root root 0 Jun 17 22:33 /tmp/z.sock
The childprocess library uses `ffi`. Historically, installing ffi has
brought challenges for fpm users. This change is an attempt to use
ruby standard methods to replace ChildProcess.
For #1795
If gem had a version constraint with just major version (e.g., ~>1),
the Debian packages were generated with wrong zero upper limit
(e.g., >= 1 and << 0). This results in unresolvable dependencies.
Signed-off-by: Vlastimil Holer <vholer@opennebula.io>
instead of a space-separated argument string
Tested with this command:
bundle exec bin/fpm --debug -s python -t deb --python-pip =pip django
And verified that safesystem() to invoke pip is given a list.
Mentioned this here:
https://github.com/jordansissel/fpm/pull/1737#discussion_r560474705
https://github.com/jordansissel/fpm/issues/1675
The value can be a number from 0 to 9 inclusive. The default mirrors
the current behavior of 9. If the --rpm-compression value is set to
"none", this value is ignored.
Setting the value to 5 sped up RPM creation on my RPM from 9 to
3 minutes.
Jordan Sissel
mszprejda
John Bollinger
John Howard
Andrey Tikhonov
Vlastimil Holer
Joris Vandermeersch
Philippe Poilbarbe
Steve Kamerman
Andreas Ulm
Arnar Gauti Ingason
Jose
vv-p
Federico Lancerin
Jeff Solomon
Julian Trzeciak