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?
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
.
Sure, no problem!
https://github.com/jordansissel/fpm/pull/1775
Most helpful comment
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 debwill 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-L235Here's where
fpm -t rpmwill convert-avalue to whatever is appropriate on Red Hat packages: https://github.com/jordansissel/fpm/blob/master/lib/fpm/package/rpm.rb#L233-L250FPM will also automatically probe for the "native" arch value by default, sometimes using
uname -mto figure it out.It might help to have fpm note this behavior in the log output, maybe? What do you think?
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.