Add DEB archive support

[gasinvein]

This requires dpkg-deb utility (part of dpkg) on host. While we could use ar p | tar x instead, using dpkg itself for this task is easier and surely more robust.
I have literally zero C programming skill, so possibly did some mistakes here.

[rh-atomic-bot]

Can one of the admins verify this patch?
I understand the following commands:

• bot, add author to whitelist
• bot, test pull request
• bot, test pull request once

[barthalion]

Are there any actual issues caused by using ar and tar? Extract utilties are used from the host and we expect packagers to include them as dependencies. I don't see it happening with dpkg, especially when it can be replaced easily.

[alexlarsson]

I don't think its a great idea to pull in a dependency on dpkg, because either all distros will need to packaged deb, or app authors can't rely on the deb support in flatpak-builder.

Anyway, debs are just ar archives, so i think we could extract them manually.

[gasinvein]

@barthalion Most nowadays .deb packages contain data.tar.xz, but xz is not the only option, so we would need list ar contents before extraction.

@alexlarsson dpkg is available on most non-deb-based distros. I believe it's beacause it's debootstrap's dependency, which is widely used for containers bootstrapping.

[refi64]

debs can just be extracted using ar, that's the underlying format. If this were to be a first class thing in flatpak-builder, you could just use ar to extract the data tarball inside and pipe the output to tar instead of having to rely on deb-specific tools.

…

On Thu, Mar 19, 2020, 10:23 AM Alexander Larsson ***@***.***> wrote: I don't think its a great idea to pull in a dependency on dpkg, because either all distros will need to packaged deb, or app authors can't rely on the deb support in flatpak-builder. Anyway, debs are just ar archives, so i think we could extract them manually. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM4YSLHTS23GG3HF4LNT23RII2HTANCNFSM4LO2X3UA> .

[alexlarsson]

@gasinvein Its available on some distros yes, but it is rarely installed. Pulling in a hard dep on it is not an easy sell.

[gasinvein]

@alexlarsson Well, how to approach this, then? Assume there is always data.tar.xz? Listing ar contents and selecting correct compression type is beyond my C skill.

[barthalion]

I can’t imagine a deb file with files structure compatible with flatpak. One way or another you will need to use the simple build system to move files around. Why not keep extraction there as well?

…

On 19 Mar 2020, at 16:58, Filippe LeMarchand ***@***.***> wrote:  @alexlarsson Well, how to approach this, then? Assume there is always data.tar.xz? Listing ar contents and selecting correct compression type is beyond my C skill. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[gasinvein]

There is already RPM archive support (via rpm2cpio), I thought it would be nice to support deb as well, especially since there are already some apps on Flathub that unpack .deb packages.

[barthalion]

Interesting, I don't think I've seen it used on Flathub. But that's fair enough.

[gasinvein]

Given that flatpak-builder already depends on the uncommon rpm2cpio utility, should I still rewrite this to use ar | tar, or is dpkg-deb acceptable?

[bbhtt]

This should indeed use ar+tar or bsdtar. Both are in the runtime but nowadays bsdtar is more widely used.

it's just a bsdtar -Oxf foo.deb 'data.tar.*' | bsdtar -xf - usually