Best method for 'outside' packages
- Anmelden oder Registrieren um Kommentare zu schreiben
New Trisquel user here, coming from Debian (and before that macos). Bought a librebooted x200 that came with Trisquel. Enjoying so far. I'm impressed.
I want to install neomutt but don't see it in the Trisquel repository. I see mutt and mutt-kz but not neomutt (which I want). What is the recommended method for obtaining 'out of repo' free software?
Coming to mind:
1. Clone from Git, compile from source (I got compile error auto.def:354: Error: couldn't exec "xmlcatalog"). This is above my competency, although it seems the purest way.
2. Temporarily add Debian jessie (or buster?) (free of course) to the sources.list. Seems dangerous that it could create out-of-sync dependencies...?
3. Same but with the Ubuntu repo.
4. Download as a binary package from debian repo, then install via apt as a local repository (so pulling all the other dependencies from trisquel repository).
5. .....?
What is the best way?
Thanks!
I am a translator!
Compiling from source can be cumbersome and you should use it as the last resort, when everything else fails. When compiling from source you will usually run into a lot of errors, because you don't have all the dependencies installed. It can be a pain in the neck to find all the right dependencies, because they are never referenced by their proper names within the repo. In short - don't compile from source unless you absolutely have to.
As a rule of thumb, don't enable repositories of other distributions, you might install something by accident that is not supposed to be there. It might not create a problem right away, but it might create a problem after the next Trisquel update rolls out.
Best option for obtaining free software that is not in Trisquel repository is adding a so-called PPA. PPAs are personal package archives, published by launchpad.net in form of apt repositories. Programmers often publish their software as a PPA, because not everyone is a contributor to the official Ubuntu repository, and not everyone wants to be. So PPAs are apt repositories that can be easily added, and the software in those repos is packaged for Ubuntu (which is good for us, since it almost always means smooth installation without any unavailable dependencies etc.)
PPAs do not always contain exclusively free software, and if they do there is no way of telling if there will be any non-free software published there in the future. Trisquel does not ship with any of the launchpad PPAs enabled because of that. But you can enable any PPA you want, it is simple and straightforward. It is advisable however to check the licensing of the software beforehand and only enable PPAs that contain free software exclusively.
If you cannot find a PPA for the program you want to install, look for a .deb package of it (in the debian repo for example, you don't even need to enable the repo in /etc/apt/sources.list, look here Debian packages search). There are GUI tools for installing single .deb packages, no need to use apt or dpkg in the console. The tool I like using is gdebi, or gdebi-kde if you are running KDE. It will basically run the dpkg command for you and show all the standard output, as well as let you look at the license of the package before installation.
Since neomutt is in debian testing repository, just go here (assuming that you run a 64-bit version of Trisquel) and download the .deb file :-)
I am a translator!
>Compiling from source can be cumbersome
Agree
>and you should use it as the last resort, when everything else fails.
Absolutely disagree
Compiling is the first way, the first option and also the last. :)
I have no idea what went wrong during the building of your source. But a stupid point: the package xml-core is installed, right?
cheers o/
I am a translator!
> Compiling is the first way, the first option and also the last. :)
why that? If all you get after compiling yourself is a runnable binary version, why not download the same runnable binary version instead and save oneself the trouble of compilation? Self-compiled programs don't show up automatically on the menu, they are not supplied by updates from the package manager, imho there are only disadvantages to compiling from source. I think of it as of a last resort when you really want to get that program, but can't do it otherwise.
Of course, there are people who insist on compiling as the only true way. As if that was not punishment enough, they will have to use Ututo instead of Trisquel (which has a much nicer name and logo after all) :-P
But on a serious note, if a program is available as a .deb, why should it be compiled from source? Especially by the majority of users who are not familiar with the process.
I am a translator!
>why that?
It's the safest way, you compile the source code (after you have read it, entirely, twice, of course..)
>why not download the same runnable binary version
It's the **un**safest way, you run a binary which you have no idea what it can do to your computer (maybe make it so that when you run it Trump pays you a visit and pretends to have dinner at your place).
>if a program is available as a .deb, why should it be compiled from source?
From bad to worse -> in such case, in order to install, during installation you are giving it sudo privileges, ay ay ay ayyyy, what's next, drinking coca-cola? :'(
I am a translator!
> From bad to worse -> in such case, in order to install, during installation you are giving it sudo privileges, ay ay ay ayyyy, what's next, drinking coca-cola? :'(
*Hides his coke behind the back* that's a root beer, I swear! *Awkward pause* Look, behind you! A three-headed monkey!
;-)
Just to complement Cyberhawk's excellent reply: GDebi will tell you what (version of what) dependency is missing to install the package you double-clicked on. You can then download those dependencies from the *same* repository and install them beforehand. However, I personally abandon that process if the the package would upgrade a library already installed on my system: the programs depending on it may malfunction after the upgrade.
It actually is the case with the "neomutt" package taken from Ubuntu 18.04's repository (the closest to Trisquel 8): it asks for an update of "libgpgme11", which itself asks for an update of "gnupg". Both packages are installed on my system and I actually use GnuPG. That is why I prefer to not follow that path.
Sorry for the late reply. Family issues lately. Thanks for the help!
>Cyberhawk, thank you so much. I appreciate how you give the answer to the general case, then the specific case :). I'd read that PPAs were a main 'feature' of Ubuntu over Debian, but I only used them once or twice.
Why do you recommend debian testing, as opposed to sid, or jessie? Just because it's new but not 'too' new?
I heard that gdebi acts as a frontend for dpkg. So that means that if there are uninstalled dependencies for the neomutt .deb, dpkg will pull them from the trisquel repository - correct?
>SuperTramp83 - I would expect nothing less than what you said, given the Stallman in your avatar :)! xml-core is not installed; I installed gcc and xsltproc (whatever that is) but didn't know what package contained the xmlcatalog executable. Thank you
>uboot, thanks that is really helpful. I would like to take some linux classes at some point, but your reply will help me get to the point where I can hopefully learn from my mistakes along the way.
>Magic Banana, thanks. So if, for example, NeoMutt required a recent-version dependency that wasn't in the Trisquel repo, I could grab it as a .deb from the Debian testing repo? As you say for one that wasn't installed.
THANK YOU
I am a translator!
You're welcome yair! I don't recommend debian testing over any other version, I'm not that much into debian to recommend one over the other. On the neomutt website, the developers have posted a link to the packaged version, which is inside debian testing repository. So, if I were bound on installing neomutt, I'd try downloading it there first.
Apparently, you might end up compiling it from source still, because there seem to be too many dependencies unresolved.
GDebi will automatically propose the installation of dependencies in versions that are available in Trisquel's repository. For missing dependencies or dependencies in newer versions than those in Trisquel's repository, GDebi will report them. You can download them from the same repository you took the .deb from, so that you know their versions will be matching the one the program expects. You may have to do the same for those dependencies, and so on.
But, again, upgrading a package already installed on your system may create problem for some some of the already installed software that depends on it and may be incompatible with a newer version of the dependency. In particular, you do not want to update fundamental libraries such as "libc6".
That is the work of the distributions to build and put together a set of packages that are compatible with each other. To a varying extent, administrators of PPAs you add (that you must trust, as SuperTramp83 points out) do that same work to make possible the installation of a few packages on a given version of a distribution. Upgrading a package in another way may create incompatibilities. And PPAs may conflict between each other.
Also, you probably do not want "to take some linux classes". You want GNU/Linux classes: https://www.gnu.org/gnu/linux-and-gnu.html
- Anmelden oder Registrieren um Kommentare zu schreiben