Fpm: deb package: architecture seemingly ignored when generating package

Created on 30 Jan 2021  Â·  5Comments  Â·  Source: jordansissel/fpm

I might be missing something stupid here, but I've tried this without the -a flag and with it. Here's the output from my CI build:

fpm -s dir -t deb -n kamelasa -v 1.0.2 -a x86_64 /home/build/...verrylongpath.../bin/kamelasa=/usr/bin/kamelasa

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}

Created package {:path=>"kamelasa_1.0.2_amd64.deb"}

I'm passing -a $(uname -m) explicitly, which resolves to -a x86_64, but the result is amd64.

If not that, can fpm give me machine readable output instead of the mix of plain text and a ruby hash?

Most helpful comment

I might be missing something stupid here

It's confusing, sorry about that. The short answer is that "x86_64" is not correct for Debian which calls this architecture "amd64". The longer answer follows, with a question for you at the end :)

The origins of x86_64 and amd64 are a bit weird. 20+ years ago, Intel was busy building Itanium (IA-64) while AMD released AMD64. At some point Itanium (intel's thing) fizzled out and AMD64 became The Way. Over time, terminology splits happened and some projects call it "amd64" while others call it "x86_64". There's some interesting stuff on wikipedia on the history.

While it's probably accurate to use amd64 and x86_64 interchangeably, different projects settled on what they would call it. Linux kernel, as you show with uname -m, calls it x86_64. Debian calls it amd64 -- example, the URL for the x86 64bit cd images: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/

On Debian, "x86_64" is not a valid package arch value. Interestingly, Red Hat is the opposite and calls this x86_64 and rejects amd64 names.

To help make this easier, fpm will automatically convert between x86_64/amd64. Similarly, Debian calls "all" what Red Hat calls "noarch" -- again, fpm will automatically convert this when necessary.

Here's where fpm -t deb will convert the -a (architecture) value to whatever is appropriate on Debian packages: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/deb.rb#L227-L235

Here's where fpm -t rpm will convert -a value to whatever is appropriate on Red Hat packages: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/rpm.rb#L233-L250

FPM will also automatically probe for the "native" arch value by default, sometimes using uname -m to figure it out.

It might help to have fpm note this behavior in the log output, maybe? What do you think?

If not that, can fpm give me machine readable output instead of the mix of plain text and a ruby hash?

At this time, fpm can only output its message format as-is. The underlying log library (cabin) can do this, but it's not exposed in fpm.

Would machine-readable output help solve this problem? I don't think I quite understand the question in the context of this issue.

All 5 comments

I might be missing something stupid here

It's confusing, sorry about that. The short answer is that "x86_64" is not correct for Debian which calls this architecture "amd64". The longer answer follows, with a question for you at the end :)

The origins of x86_64 and amd64 are a bit weird. 20+ years ago, Intel was busy building Itanium (IA-64) while AMD released AMD64. At some point Itanium (intel's thing) fizzled out and AMD64 became The Way. Over time, terminology splits happened and some projects call it "amd64" while others call it "x86_64". There's some interesting stuff on wikipedia on the history.

While it's probably accurate to use amd64 and x86_64 interchangeably, different projects settled on what they would call it. Linux kernel, as you show with uname -m, calls it x86_64. Debian calls it amd64 -- example, the URL for the x86 64bit cd images: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/

On Debian, "x86_64" is not a valid package arch value. Interestingly, Red Hat is the opposite and calls this x86_64 and rejects amd64 names.

To help make this easier, fpm will automatically convert between x86_64/amd64. Similarly, Debian calls "all" what Red Hat calls "noarch" -- again, fpm will automatically convert this when necessary.

Here's where fpm -t deb will convert the -a (architecture) value to whatever is appropriate on Debian packages: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/deb.rb#L227-L235

Here's where fpm -t rpm will convert -a value to whatever is appropriate on Red Hat packages: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/rpm.rb#L233-L250

FPM will also automatically probe for the "native" arch value by default, sometimes using uname -m to figure it out.

It might help to have fpm note this behavior in the log output, maybe? What do you think?

If not that, can fpm give me machine readable output instead of the mix of plain text and a ruby hash?

At this time, fpm can only output its message format as-is. The underlying log library (cabin) can do this, but it's not exposed in fpm.

Would machine-readable output help solve this problem? I don't think I quite understand the question in the context of this issue.

Thanks for the detailed response! Should it be contributed to the wiki rather than changing the code to log the discrepancy?

Happy to contribute an addition to change the output to be machine readable.

Just to add some pain to this problem, this has happened again with the 64-bit ARMv8 architecture. The official name (in the kernel) is aarch64, but Debian requires arm64.

Maybe someone should put another case here?:
https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/deb.rb#L227-L235

I can put in a PR if you want, but I can't really test it (other than to confirm that deb files do not work with Architecture: aarch64). The default configuration of passing uname -m on an ARM 64 machine to fpm produces deb files that are unusable with the following error:

dpkg: error processing archive package.deb (--install):
 package architecture (aarch64) does not match system (arm64)

For reference, you can install a package that has the wrong architecture like dpkg -i --force-architecture something.deb

Oh good find! If you don’t mind, open a new issue for this specific
arm64s/Debian issue. I can test your PR if you have energy to write one :)

On Fri, Mar 26, 2021 at 10:08 AM Steve Kamerman @.*>
wrote:

Just to add some pain to this problem, this has happened again with the
64-bit ARMv8 architecture. The official name (in the kernel) is aarch64,
but Debian requires arm64.

Maybe someone should put another case here?:

https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/deb.rb#L227-L235

I can put in a PR if you want, but I can't really test it (other than to
confirm that deb files do not work with Architecture: aarch64). The
default configuration of passing uname -a on an ARM 64 machine to fpm
produces deb files that are unusable with the following error:

dpkg: error processing archive package.deb (--install):
package architecture (aarch64) does not match system (arm64)

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/jordansissel/fpm/issues/1762#issuecomment-808378062,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABAF2QJWMQT7Z4OWZEUS4TTFS5QXANCNFSM4W2WPL6A
.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hellosputnik picture hellosputnik  Â·  7Comments

jean-christophe-manciot picture jean-christophe-manciot  Â·  4Comments

dogonthehorizon picture dogonthehorizon  Â·  3Comments

samueljc picture samueljc  Â·  4Comments

leandro-lucarella-sociomantic picture leandro-lucarella-sociomantic  Â·  10Comments