Fix for #1627

[JordanStopford]

When packaging a deb sometimes the architecture comes through as part of the provides (not sure why) but this causes problems with the deb package as it seems to only ever expect one set of round brackets which is the version indicator Also fixed another issue where ppc64le packages from RPM wouldn't install properly on DEB based systems as they use ppc64el. Also fixed another issue where invalid dependencies were being put in the control file (rpmlib dependencies and file path dependencies i.e. RPMs that depend on /bin/sh)

This has got fpm working for RPMs->DEBs on our systems for ppc64le packages. Appreciate that this fix might not be "complete" or comprehensive in any way, shape or form so any feedback is welcome.

[jordansissel]

I haven’t tested this, but the change seems like it’s a good solution. @JordanStopford you ok with me merging?

[JordanStopford]

We’ve done some testing internally (mainly Ubuntu on PowerPC little endian) and it does fix the issue with our RPM conversion.

I found another similar issue today with dependency scanning and have pushed some more commits to my repo. Do you want those in a separate PR? These changes centered around two issues:

1. Dependencies on binaries (like /bin/sh) don’t seem to be allowed in dpkg control files so these are now stripped out
2. RPM specific dependencies (like rpmlib) were being passed through and shouldn’t be

On Tue, 23 Apr 2024 at 20:54, Jordan Sissel @.***> wrote:

I haven’t tested this, but the change seems like it’s a good solution. @JordanStopford https://github.com/JordanStopford you ok with me merging?

— Reply to this email directly, view it on GitHub https://github.com/jordansissel/fpm/pull/2053#issuecomment-2073322835, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEN7W2V4FHDAVJG2CMQ2D3Y624ANAVCNFSM6AAAAABEMTAAL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGMZDEOBTGU . You are receiving this because you were mentioned.Message ID: @.***>

[jordansissel]

It’s ok 👍 to include multiple changes in a single PR. My request for keeping this one PR is to update the PR description to refer to the things you improve.

Otherwise, yes, all changes look like good improvements :)

[JordanStopford]

@jordansissel I've amended the PR description above. Thanks for your feedback!

[jordansissel]

I tested manually with the example from #1627 (smartmontools from OpenSUSE, and I confirmed the error without this patch:

Invalid relationship field for debian package: config(smartmontools) = 7.4-2.3 {:level=>:error}
Invalid package configuration: Found invalid Provides field values ("config(smartmontools) = 7.4-2.3"). This is not valid in a Debian package. {:level=>:error}

Testing your patch looks good:

% bundle exec bin/fpm -s rpm -t deb smartmontools-7.4-2.3.x86_64.rpm
...
Created package {:path=>"smartmontools_7.4-2.3_amd64.deb"}

# Check the `Provides` field in the resulting 'deb' file:
% ar p smartmontools_7.4-2.3_amd64.deb control.tar.gz | tar -zxO ./control | grep Provides:
Provides: smartmontools (= 7.4-2.3)