During my search for a good Markdown text editor for Linux, I came across a few that had binary installation only for Debian and Ubuntu distributions. See The search for a usable Markdown editor for my Linux desktop.
Because my main Linux desktop is powered for Fedora, I decided to find an alternate method of installing those applications other than compiling them from source. Call it a lazy approach, but sometimes you have to find shortcuts.
The only other method that I am aware of is to use alien to convert the .deb package to a .rpm package, then install the generated RPM package using either yum or alien itself. Unfortunately, all my attempts at that failed.
Here’s what happened.
1. For Atom, the best Markdown-capable editor that I came across, the reason it failed was because libchromiumcontent.so was required, but it could not be installed. There’s a lengthy discussion about issues with libchromiumcontent.so on GitHub, but no suggestion there solved the installation attempt of an alien-generated file.
2. For Haroopad, another very good Markdown-capable editor, the problem was with libudev.so.0. I spend almost three hours trying to find a workaround to this one. Yep, I tried symlinking to libudev.so.1.5.x and libudev.so.1 but it didn’t work. I even tried <strong>yum distro-sync</strong> to no avail.
3. The last attempt was with Springseed, but the reason for failure was slightly different. Couldn’t make head or tail out of the error, so I gave up on it. Will take another stab at it later.
So using alien to generate an RPM package from a DEB package is easy. Installing the generated RPM package is where the headache awaits. By the way, to install alien on Fedora, type: <strong>yum install alien</strong>.
Ok. First, you don’t show the commands you are running to try to install these packages, so this is just guesswork.
If you are using yum to install the packages created by alien, then I would run the following command as root:
yum -y localinstall package_name.rpm
This would allow yum to try to resolve the library dependencies for you. If that didn’t solve the problem, then:
yum whatprovides */libchromiumcontent.so
And if this doesn’t solve the problem, then you would probably have to download and build the dependencies manually.
The last problem is because the person who created the .deb file incorrectly includes / and /usr/bin in their filelist when they shouldn’t have.
All in all, the problem isn’t with how alien is creating the RPMs , it’s the dependencies that are an issue and an incorrectly built .deb package.
So what I’m saying is don’t blame the alien tool. The problem is that translating dependencies between Debian and RPM based systems isn’t always as straight forward as it seems.
As a fellow Fedora 20 x64 user, I have made the same experiences with “alien”. To get Atom running, I instead followed these instructions to build from source: https://gist.github.com/mojavelinux/225d01e621f467db1c75
Thanks for mentioning gitbook in your related article, I somehow missed that project entirely!
Fixing its install script is trivial indeed.
It tries to symlink “/usr/lib64/libudev.so.1”, a file that does not exist on Fedora 20 x64. Changing it to “/usr/lib64/libudev.so” yielded success.
Thanks, but that was not even the problem I had with the script. In the script, there’s a variable called USER which is set to the whoami command.
The issue is it references that variable to determine where to install the application. Since it has to be installed as root or via sudo, whoami returns the home directory of root, and not the standard user’s home directory. The solution I thought was to pass USER the pwd -P command, but that didn’t work. I can see the problem with that, because pwd -P returns the directory from which the script is being run, which is from the ~/GitBook directory.
What’s the best method of assigning the home directory of the standard user to USER in that script, so that the application’s desktop shortcut is installed to /home/finid, for example, and not to /home/root?
I have no answer to that, but why do you even want to install with root permissions?
All the installer does is create/symlink files in “~/.gitbook”, “~/.local/share/applications” and “~/Desktop” and use xdg-desktop-menu. None of the above needs root permissions!
Ha, ok, I didn’t realize that. Just tried it and it worked. GitBook looks good. Thanks.
That’s strange. On my Fedora 20 KDE desktop, libudev.so.1 is a symlink to libudev.so.1.4.0. So it does, in a way, exist. On Rawhide, it symlinks to libudev.so.1.5.0
You’re absolutely correct!
I got confused with “.so.1″ .”so.0” when I initially used Gitbook directly (without installing) and created a symlink myself.
My original comment on the symlink issue can be disregarded.