Created RPM package conflicts with file from package filesystem (gossip transfered via alien)

Ask Fedora
,
1

I transformed .deb package with alien but when I want to install it (on fedora) I get file /usr/bin from install of gossip-0.7.0-2.x86_64 conflicts with file from package filesystem-3.18-3.fc38.x86_64
[Release 0.7.0 · mikedilger/gossip · GitHub](https://source deb package)
Should somehow link that filesys package with the gossip or?

2

Converting packages from .deb to .rpm often seems ridiculously easy. The difficulty remains that dependencies within the packages may not be compatible and that is a perfect example. The fedora filesystem package should always be the controlling one in that case.

Unless one is able to resolve dependencies it seems better to avoid such conflicts.

3

Multiple packages are allowed to own the same directories or files - provided they are identical (same owners and permissions, and for files, same content).

In this case I am guessing the permissions are mismatched.

I would suggest just getting it packaged in Fedora, but it’s a Java package… ouch. That’s tricky as a lot of these are really hard to build from source, though if Debian can do it Fedora probably can.

Can you either download a JAR from upstream, or unpack the archive with bsdtar xf?

4

While I have not tested, I would assume this also may apply to SELinux context as well.

1 Like
5

Good point, I think it does.

6

java? gossip is written in Rust

7

Huh, duh, I was looking up the Debian package and was misled by this

https://packages.debian.org/search?keywords=gossip

If it’s Rust … I might take a look at packaging it. Won’t be 100% straightforward as it’s not on crates.io but hopefully its dependencies are

8

That depends on which gossip project we are looking at. Fedore used to distribute the one from https://github.com/jdillon/gossip, which is a maven project, thus java.

9

Right. But my bad, the one OP clearly pointed out in the first post is Rust. The Debian package came from the upstream GitHub, not from the Debian project

10

That sounds like your package claims ownership of /usr/bin and that’s
already owned by filesystem. Check the %files section of the spec file.