[Solved] Missing "libiconv.so.2", can't use makepkg.

Belaros · 2019-02-22 16:17:15

Hi, I can't use makepkg because of an error stemming from bsdtar about the library libiconv.so.2. For example this is the outpu if I try to install jetbrains-toolbox, but it happens for any other AUR package:

==> Making package: jetbrains-toolbox 1.13.4801-1 (Fri 22 Feb 2019 10:10:45 AM CST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found jetbrains-toolbox-1.13.4801.tar.gz
  -> Found jetbrains-toolbox.desktop
==> Validating source files with sha512sums...
    jetbrains-toolbox-1.13.4801.tar.gz ... Passed
    jetbrains-toolbox.desktop ... Passed
==> Extracting sources...
  -> Extracting jetbrains-toolbox-1.13.4801.tar.gz with bsdtar
bsdtar: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory
==> ERROR: Failed to extract jetbrains-toolbox-1.13.4801.tar.gz
    Aborting...

If I just run bsdtar I get the same error:

bsdtar: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory

I tried pkgfile but nothing comes up.

The only things I've found about libiconv are that it's an old library that sould be avoided. Maybe I'm missing some system link to an equivalent library?

I'll appreciate any help on this.

Last edited by Belaros (2019-02-24 22:02:05)

Scimmia · 2019-02-22 16:19:46

What does `which bsdtar` give you?
How about lddtree (from the pax-utils package) on that binary?

Belaros · 2019-02-22 17:04:45

Thanks, your questions gave me enough input to solve this problem. I'll go through what I did in case anyone else gets the same problem.

I hadn't even thought of doing `which bsdtar`. Apparently Anaconda came with its own bsdtar and that was the one that was being called, output was:

/home/[user]/anaconda3/bin/bstar

So I tried running the normal bsdtar from `/usr/bin/bsdtar` and there was no error. So I tried `lddtree` on both binaries and sure enough they were different. For Anaconda's bsdtar I got this (notice libiconv.so.2 to "None"):

/home/[user]/anaconda3/bin/bsdtar (interpreter => /lib64/ld-linux-x86-64.so.2)
    libiconv.so.2 => None
    libcrypto.so.1.0.0 => /home/[user]/anaconda3/lib/libcrypto.so.1.0.0
        libdl.so.2 => /usr/lib/libdl.so.2
    liblzo2.so.2 => /home/[user]/anaconda3/lib/liblzo2.so.2
    liblzma.so.5 => /home/[user]/anaconda3/lib/liblzma.so.5
        librt.so.1 => /usr/lib/librt.so.1
        libpthread.so.0 => /usr/lib/libpthread.so.0
    libzstd.so.1 => /home/[user]/anaconda3/lib/libzstd.so.1
    liblz4.so.1 => /home/[user]/anaconda3/lib/liblz4.so.1
    libbz2.so.1.0 => /home/[user]/anaconda3/lib/libbz2.so.1.0
    libz.so.1 => /home/[user]/anaconda3/lib/libz.so.1
    libxml2.so.2 => /home/[user]/anaconda3/lib/libxml2.so.2
        libicuuc.so.58 => /home/[user]/anaconda3/lib/libicuuc.so.58
            libicudata.so.58 => /home/[user]/anaconda3/lib/libicudata.so.58
            libstdc++.so.6 => /home/[user]/anaconda3/lib/libstdc++.so.6
            libgcc_s.so.1 => /home/[user]/anaconda3/lib/libgcc_s.so.1
        libm.so.6 => /usr/lib/libm.so.6
    libc.so.6 => /usr/lib/libc.so.6

The binary at `/usr/bin/bsdtar` was giving me completely different output (no mention of libiconv):

/usr/bin/bsdtar (interpreter => /lib64/ld-linux-x86-64.so.2)
    libarchive.so.13 => /usr/lib/libarchive.so.13
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
            libdl.so.2 => /usr/lib/libdl.so.2
            libpthread.so.0 => /usr/lib/libpthread.so.0
        libacl.so.1 => /usr/lib/libacl.so.1
            libattr.so.1 => /usr/lib/libattr.so.1
        libexpat.so.1 => /usr/lib/libexpat.so.1
        liblzma.so.5 => /usr/lib/liblzma.so.5
        libzstd.so.1 => /usr/lib/libzstd.so.1
        liblz4.so.1 => /usr/lib/liblz4.so.1
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
        libz.so.1 => /usr/lib/libz.so.1
    libc.so.6 => /usr/lib/libc.so.6

So after all this the way I solved it was by fixing Anaconda's bsdtar, by running `conda install libiconv`. After running this I was able to successfully run bsdtar by itself and also to run makepkg.

Thanks again.

eschwartz · 2019-02-22 18:18:52

I'd suggest not using anaconda at all, when you could simply use python and install modules from pacman or else pip, and optionally using a virtualenv -- the main use case of anaconda seems to be for Windows data scientists, who cannot easily compile binary modules using pip as Windows compiler toolchains are annoying to set up.

If you must use anaconda, do not add it to the PATH so that it becomes the default python -- that will break other software on the system which assumes that the default python is the one that is in /usr/bin/python, which may be a different version of python (is it python 3.6 or 3.7? Is it 3.7.2 specifically?), and which won't have the availability of the system packages which pacman installed as dependencies.

When using anaconda, you should be manually sourcing the script that adds it to the PATH for your current session only.

Trilby · 2019-02-22 20:21:54

eschwartz wrote:

I'd suggest not using anaconda at all

Emphatically seconded.

eschwartz wrote:

the main use case of anaconda seems to be for Windows data scientists, who cannot easily compile binary modules using pip as Windows compiler toolchains are annoying to set up.

Even in Windows I've seen it do far more harm than good. It's not hard at all to build everything needed in Windows. So I'd revise the above to state that the main use case of anaconda seems to be for Windows data scientists who don't know the first thing about how computers work. Sadly such people are disturbingly common.

Belaros · 2019-02-23 01:25:52

I appreciate the suggestion. However Anaconda is a non-negotiable and I'll continue using it as my default Python. I'm well aware of Anaconda's use case (not what it "seems" to be) and I'm not willing to spend the time getting pip/virtualenv to work like conda environments (try running a Python application with a bunch of non-Python dependencies on YARN without using conda environments) or hunting around MKL packages or any other conda package which may or may not exist in the AUR. We've been using Anaconda on Ubuntu for the last 3 years in our organization without a problem, so at least I know that if any serious issue arises I can go back to where it works.

Last edited by Belaros (2019-02-23 01:57:14)

seth · 2019-02-23 08:57:36

Also "non-negotiable":

eschwartz wrote:

When using anaconda, you should must be manually sourcing the script that adds it to the PATH for your current session only.

Translation: keep that shit out of your regular shells, also ensure it's not polluting your LD_LIBRARY_PATH.
https://conda.io/projects/conda/en/late … ments.html

eschwartz · 2019-02-24 20:17:35

Belaros wrote:

I appreciate the suggestion. However Anaconda is a non-negotiable and I'll continue using it as my default Python.

I don't really care if you want to suffer through anaconda. However, overriding the default python means that you are no longer using Arch Linux packages for *any* python software on your system. There's quite a lot of software on Linux that utilizes python -- I hope you don't mind if we automatically reject any and all support threads you ever open, the first time we discover it involves python?

I'm well aware of Anaconda's use case (not what it "seems" to be)

That is what conda is for -- not what anaconda is for. It is also what virtualenv is for... or alternatively, just like virtualenv should never be the default python, so too, anaconda (which is essentially a very fancy virtualenv for the interpreter as well as a custom package manager) should never be the default python.

and I'm not willing to spend the time getting pip/virtualenv to work like conda environments (try running a Python application with a bunch of non-Python dependencies on YARN without using conda environments)

While I acknowledge it is not possible within python setup.py to install such YARN dependencies via pacman, it is possible to watch the error messages, install them via pacman, and restart the installation.

I'm a bit annoyed by your insinuation that I've never tried to build or run python applications with non-python dependencies, as in fact I do this all the time -- it is, fundamentally, what the job of a PKGBUILD is, and I am a Trusted User and therefore responsible for, well, building packages, some of which are python-based and therefore depend on non-python dependencies fairly often.

It is most definitely possible. It's also, even, easy. It does, however, take an investment in time -- and I signed up to be a package maintainer on Arch, you did not, so I would understand if you didn't want to spend your time on this, I do not understand your suggestion that it is somehow unworkable or even hard. 80% of the time a trained monkey with time on its hands can do it.

or hunting around MKL packages or any other conda package which may or may not exist in the AUR.

I think it would be great if the Arch Linux environment had a healthy MKL ecosystem. I don't really know anything about it myself, but there appear to be other people doing the same thing: you can get both numpy and scipy in -mkl suffixed editions from the AUR. In general the process should be somewhat simple when working from the existing package as a base. I'd imagine you just need to add intel-mkl as a dependency and then redirect the compiler.

We've been using Anaconda on Ubuntu for the last 3 years in our organization without a problem, so at least I know that if any serious issue arises I can go back to where it works.

If you need to move all the way to Ubuntu to fix the problem, then, um, okay. But when "serious issues" means that anaconda is literally overriding all the software on your entire operating system without you realizing it, so you cannot even get things like bsdtar to work, then you should definitely reconsider what the actual problem is.

Once again: I don't care if you use anaconda for specific purposes. Do whatever floats your boat. Just please don't make it your *default*, because then you do things like, well, breaking bsdtar and makepkg.

If the lesson you learned from this was to continue to use anaconda's custom bsdtar with unknown options, versions, and archive support, that unpredictably links ancient libraries but, ironically, does not make use of conda's dependency management in order to depend on vital runtime support libraries, then and only then, do I wash my hands of you.

Belaros · 2019-02-24 22:01:40

While I acknowledge it is not possible within python setup.py to install such YARN dependencies via pacman, it is possible to watch the error messages, install them via pacman, and restart the installation.
I'm a bit annoyed by your insinuation that I've never tried to build or run python applications with non-python dependencies, as in fact I do this all the time -- it is, fundamentally, what the job of a PKGBUILD is, and I am a Trusted User and therefore responsible for, well, building packages, some of which are python-based and therefore depend on non-python dependencies fairly often.
It is most definitely possible. It's also, even, easy. It does, however, take an investment in time -- and I signed up to be a package maintainer on Arch, you did not, so I would understand if you didn't want to spend your time on this, I do not understand your suggestion that it is somehow unworkable or even hard. 80% of the time a trained monkey with time on its hands can do it.

There might have been a miscommunication. I wasn't talking about the package manager yarn (that I just now learned existed). I was referring to Hadoop YARN, the kernel-like component of the Hadoop ecosystem. I meant running on YARN as in YARN is in charge of running the application. With conda I can make a zip of my environment (either binaries or a list of packages I want conda to install, or a mix of both), including non-Python packages, and tell YARN to take that zip and distribute it to every node (these are production servers, so they would be running another distro). The alternative to this would be to SSH into each individual node and use the package manager there to run the dependencies. And then when I'm done and I decide the package I was trying out wasn't good I go back to each one and uninstall it. This is assuming I have sudo privileges for each node. Of course it's not unworkable, even without sudo it's doable, but it's really not worth my time, especially when I could be doing this multiple times a day.

All these things quickly add up. They may be easy but that's not what matters. It's still work that's otherwise needless.

So alright, none of this matters because I can get everything out of my path and manually activate anaconda. Every time. That's just an annoyance I didn't have before. This issue doesn't occur on other distros and since I can't get it to behave the way I want it to (that's the whole point, isn't it?) then I'd have to say this one is frankly less capable.

If makepkg depends on pacman's bsdtar, then why isn't it simply calling `/usr/bin/bsdtar`? Otherwise it seems to want to use whatever is in my path, and that's exactly what it gets. Any script that starts with `#!/usr/bin/python` will use the native Python and won't even realize Anaconda exists, only the ones using `/usr/bin/env` will be affected, and that's because they've specifically asked for it. Sure, I can take steps to avoid it, but why make it so brittle in the first place?

seth · 2019-02-24 22:09:45

You do understand that
1. this goes beyond bsdtar and makepkg - you just randomly ran into this particular issue?
2. anaconda installs a broken bsdtar binary, what caused your problem itfp.?

eschwartz · 2019-02-24 22:20:14

Belaros wrote:

There might have been a miscommunication. I wasn't talking about the package manager yarn (that I just now learned existed). I was referring to Hadoop YARN, the kernel-like component of the Hadoop ecosystem. I meant running on YARN as in YARN is in charge of running the application. With conda I can make a zip of my environment (either binaries or a list of packages I want conda to install, or a mix of both), including non-Python packages, and tell YARN to take that zip and distribute it to every node (these are production servers, so they would be running another distro). The alternative to this would be to SSH into each individual node and use the package manager there to run the dependencies. And then when I'm done and I decide the package I was trying out wasn't good I go back to each one and uninstall it. This is assuming I have sudo privileges for each node. Of course it's not unworkable, even without sudo it's doable, but it's really not worth my time, especially when I could be doing this multiple times a day.
All these things quickly add up. They may be easy but that's not what matters. It's still work that's otherwise needless.

Hmm, is this deployment method not capable of for example running a custom command?

So alright, none of this matters because I can get everything out of my path and manually activate anaconda. Every time. That's just an annoyance I didn't have before. This issue doesn't occur on other distros and since I can't get it to behave the way I want it to (that's the whole point, isn't it?) then I'd have to say this one is frankly less capable.
If makepkg depends on pacman's bsdtar, then why isn't it simply calling `/usr/bin/bsdtar`? Otherwise it seems to want to use whatever is in my path, and that's exactly what it gets. Any script that starts with `#!/usr/bin/python` will use the native Python and won't even realize Anaconda exists, only the ones using `/usr/bin/env` will be affected, and that's because they've specifically asked for it. Sure, I can take steps to avoid it, but why make it so brittle in the first place?

Well, I have no idea why it did not occur on other distros.

But as for shebangs with /usr/bin/python vs. /usr/bin/env python, I thoroughly agree with you. Unfortunately we're working against an extremely thorough legacy of python recommendations that everything should always use env, in order to sidestep the package manager -- it is bizarre advice, but it is also extremely prevalent, so you cannot know what you are going to break, and in fact lots of things will use the ugly "env python" -- including users' custom python scripts and projects cloned from github. Because the internet told them to use env.

Also, it doesn't help when software executes the python command in a shellscript. Which some programs do by installing a shellscript launcher that runs e.g. (comunity/reflector)
python3 -m Reflector "$@"

Do you suppose any writer of shellscripts is going to encode all commands as /usr/bin/bsdtar /usr/bin/cat /usr/bin/cp /usr/bin/python /usr/bin/rm /usr/bin/this /usr/bin/that? No...

Also, it would break use cases like macOS, which I don't believe has bsdtar by default and you'll need to install it from macports/homebrew. This means you cannot rely on it being in the specific element of the system path, which happens to be /usr/bin -- instead, we assume that the user does not have a broken bsdtar on their path, which is not properly integrated into their OS. At least we assume that the user knows which bsdtar they have.

pacman is a multi-distro and multi-OS package manager -- we have downstream users on Windows (the MSYS2 platform is powered by pacman) as well as macOS. There is or was also a BSD port that used pacman...

(BTW: pacman -S conflict and run "conflict", to find the general case of conflicting executable commands on your current PATH.)

Belaros · 2019-02-24 22:25:54

seth wrote:

You do understand that
1. this goes beyond bsdtar and makepkg - you just randomly ran into this particular issue?
2. anaconda installs a broken bsdtar binary, what caused your problem itfp.?

Might be a deeper problem, but it's one of design, makepkg could just be a symptom.

A curious thing, makepkg's shebang is `#!/usr/bin/bash` and not `#!/usr/bin/env bash`. It's good that it doesn't ask for the environment's bash, so I'm free to have whatever I want aliased to bash (at least as far as makepkg is concerned). Why not with the rest of the programs it calls? Easy fix for makepkg, set path to `/usr/bin` at the start of the script. Now it won't fail due to anaconda and I'm free to have my path however I want it. If other programs are tightly coupled to my path variable then they should be changed also.

eschwartz wrote:

Do you suppose any writer of shellscripts is going to encode all commands as /usr/bin/bsdtar /usr/bin/cat /usr/bin/cp /usr/bin/python /usr/bin/rm /usr/bin/this /usr/bin/that? No...

Surely either the path variable can be changed at the start of the script depending on the OS in use, or a different prefix variable can be used to call `$PREFIX/bsdtar`. And this isn't about "any" writer of shellscripts, it's a good practice in general and should be standard for such vital scripts as makepkg.

I wasn't aware pacman was supposed to be multiplatform. Having a package manager tailored to Arch's needs could be a good idea. But I'm way out of my depth here.

eschwartz wrote:

Hmm, is this deployment method not capable of for example running a custom command?

Sure, I could even run the command from within the Python scripts I'm deploying. But it's definitely a hassle. The YARN user won't have sudo priviledges for one so this makes it even more of a nuissance. I'm not saying it's impossible or anything of the sort. I'm saying it takes (work) time and is otherwise unproductive. I'm also not the only person using the Hadoop cluster and I wouldn't want other people to be using these sorts of commands that could leave the servers full of weird packages we only used once for a benchmark.

Last edited by Belaros (2019-02-24 22:39:59)

seth · 2019-02-24 22:35:46

It would also not fail if you didn't shadow binaries with broken ones…

Most scripts won't make full path calls simply for redistribution issues (esp. before systemd simply squashed most binary paths) and at times users have actually good reasons to alias or shadow binaries.
Let alone the impact on human users, do I always have to fire /usr/bin/mutt so anaconda is free to shadow mutt w/ a dysfunctional variant?

The *only* problem here is that your second level distro rambo'd in a broken binary, because it apparently installs stuff w/o proper dependency resolution (why did you have to install libiconv - leaving aside that this is now gone for a decade or so - if it's clearly a dependency for whatever installed the anaconda bsdtar binary - isn't that what you're claiming conda is better at than any other package manager?)

Belaros · 2019-02-24 23:12:43

seth wrote:

at times users have actually good reasons to alias or shadow binaries.

You can still alias `/usr/bin/python` to whatever, or use symlinks. I'm not trying to force the point, it's a suggestion of how I think this could be made more stable. Pacman can't know (or shouldn't) what's in my path, so instead of making assumptions it can work with what it knows. A bit of poka-yoke.

Let alone the impact on human users, do I always have to fire /usr/bin/mutt so anaconda is free to shadow mutt w/ a dysfunctional variant?

Once you get to this point it's the user screwing his own path for his own calls. What I mean is that I think users should be able to own their path and system programs should respect that. I'm aware it's a more... philosophical point.

The *only* problem here is that your second level distro rambo'd in a broken binary, because it apparently installs stuff w/o proper dependency resolution (why did you have to install libiconv - leaving aside that this is now gone for a decade or so - if it's clearly a dependency for whatever installed the anaconda bsdtar binary - isn't that what you're claiming conda is better at than any other package manager?)

It's not what I'm claiming. I only use Anaconda's packages for Python related stuff, and that's where it's better at than other package managers, I gave an example before of one of its cool features: deploying to a cluster of different computers that may have different distros and different packages installed natively.

The fix I mentioned above wasn't actually installing libiconv, but rather updating it. I checked on another computer with an older version of anaconda and I see that it used to provide its own libiconv.so.2. I admit I have no idea why my own anaconda install was left in such an inconsistent state.

This is how it looks in the older anaconda:

libiconv.so.2 => /home/[user]/anaconda3/bin/../lib/libiconv.so.2

The updated version doesn't use libiconv.so.2 at all.

Last edited by Belaros (2019-02-24 23:15:51)

eschwartz · 2019-02-24 23:43:42

Belaros wrote:

Might be a deeper problem, but it's one of design, makepkg could just be a symptom.
A curious thing, makepkg's shebang is `#!/usr/bin/bash` and not `#!/usr/bin/env bash`. It's good that it doesn't ask for the environment's bash, so I'm free to have whatever I want aliased to bash (at least as far as makepkg is concerned). Why not with the rest of the programs it calls? Easy fix for makepkg, set path to `/usr/bin` at the start of the script. Now it won't fail due to anaconda and I'm free to have my path however I want it. If other programs are tightly coupled to my path variable then they should be changed also.

Actually it still executes "bash" via a subprocess with $PATH lookup. But the current methodology means it works if the shebang has been configured at compile time, to use a shell in e.g. /usr/local/bin (like on BSD).

Belaros wrote:

eschwartz wrote:
Do you suppose any writer of shellscripts is going to encode all commands as /usr/bin/bsdtar /usr/bin/cat /usr/bin/cp /usr/bin/python /usr/bin/rm /usr/bin/this /usr/bin/that? No...
Surely either the path variable can be changed at the start of the script depending on the OS in use, or a different prefix variable can be used to call `$PREFIX/bsdtar`. And this isn't about "any" writer of shellscripts, it's a good practice in general and should be standard for such vital scripts as makepkg.
I wasn't aware pacman was supposed to be multiplatform. Having a package manager tailored to Arch's needs could be a good idea. But I'm way out of my depth here.

It is tailored to Arch's needs, but we also try to be portable. Some other platforms are similar enough in spirit to Arch, that pacman is useful to them as well.

And you're still trying to special case bsdtar and makepkg, when the problem is that you have added an unknown number of binaries to your PATH, which shadow the system ones.

"Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. " I might want to shadow some binaries, with the knowledge that e.g. makepkg was designed in order to work properly on systems where the core utilities, find, etc. are provided by the BSD base or from busybox. I might want to experiment with my carefully chosen modifications to bsdtar, too -- what if libarchive 3.3.3 was not yet released, but I wanted to experiment with the git master version that had zstd support?

Running with a strictly defined PATH is something very very few scripts do, and in those cases it is being done for security sandboxing reasons, not to prevent breakage.

Belaros wrote:

seth wrote:
at times users have actually good reasons to alias or shadow binaries.
You can still alias `/usr/bin/python` to whatever, or use symlinks. I'm not trying to force the point, it's a suggestion of how I think this could be made more stable. Pacman can't know (or shouldn't) what's in my path, so instead of making assumptions it can work with what it knows. A bit of poka-yoke.

Correct! You yourself can also shadow *just* python, and not *also* strange things like bsdtar.

As I've mentioned several times, the best solution here would be to only run anaconda from within an interactively spawned session, or from whichever startup process you use to run background data science procedures.

Trilby · 2019-02-24 23:58:57

eschwartz wrote:

As I've mentioned several times, the best solution here would be to only run anaconda from within an interactively spawned session, or from whichever startup process you use to run background data science procedures.

I agree, but Belaros already rejected this:

Belaros wrote:

I can get everything out of my path and manually activate anaconda. Every time. That's just an annoyance I didn't have before.

So, we have to deal with all this shadowing and aliasing of countless tools rather than just creating one simple alias something like:

alias anaconda='export PATH=/path/to/anaconda/stuff:$PATH; anaconda'
# or maybe something like the following, I don't use anaconda
alias python='export PATH=/path/to/anaconda/stuff:$PATH; python'

Last edited by Trilby (2019-02-25 00:02:59)

Belaros · 2019-02-25 01:22:14

eschwartz wrote:

As I've mentioned several times, the best solution here would be to only run anaconda from within an interactively spawned session, or from whichever startup process you use to run background data science procedures.

So, we have to deal with all this shadowing and aliasing of countless tools rather than just creating one simple alias something like:
alias anaconda='export PATH=/path/to/anaconda/stuff:$PATH; anaconda'
# or maybe something like the following, I don't use anaconda
alias python='export PATH=/path/to/anaconda/stuff:$PATH; python'

I've understood this. I understand what the problem was, why it's a problem and how to fix it. And thanks for bearing with me. For example I can always run `conda activate` to get into the conda environment and `conda deactivate` to be back to normal, this comes built in.

Now that that's done, separate from that, I'm trying to make a suggestion. I can make a new thread somewhere else if you'd like, if it's more appropriate. But it feels like a continuation of the discussion.

And the suggestion is what I've said before: make system programs more robust by not making assumptions about the Path variable. I used makepkg because that's the example at hand, but I think it should be a good/suggested practice for all system programs. This is analogous to how `/usr/bin` should be considered safe for the system's package manager but `/usr/local/bin` can have anything. So what I propose is that on principle pacman and other system programs shouldn't trust the user's path. And I don't think it's such a crazy idea since stuff like Anaconda does add itself to the path on installation (Anaconda specifically asks if you want it with "No" by default). This is poka-yoke, don't let the user break the system unless he's trying to. Like for example aliasing something in /usr/bin. You can still do the stupid thing, but you'll have to be more deliberate going about it. You can be sure programs like Anaconda won't try to do such a thing in their installers. That way you also won't get people like me posting here with such problems.

Going along this line, I went and checked how others did this. I'm continuing with my example of makepkg but that's just to pick something. Here's some thing similar, from apt-get's source code. Lines of interest are 38 to 42. That's where the compression applications are defined. I'll quote that here:

	// Set default application paths to check for optional compression types
	_config->CndSet("Dir::Bin::gzip", "/bin/gzip");
	_config->CndSet("Dir::Bin::bzip2", "/bin/bzip2");
	_config->CndSet("Dir::Bin::xz", "/usr/bin/xz");
	_config->CndSet("Dir::Bin::lz4", "/usr/bin/lz4");
	_config->CndSet("Dir::Bin::zstd", "/usr/bin/zstd");

So I could have a file called "gzip" in my local path that just runs `systemctl poweroff` and I'd still be able to install (and by extension decompress) packages on apt-get without having any issue. No matter what's in my path, if I run apt it's going to use the gzip or bzip2 or whatever is located in /usr/bin.

I'm aware there could be a significant amount of packages that would have to be changed. But it's just as doable as when it was decided that package managers don't touch /usr/local/bin and generic makefiles shouldn't touch /usr/bin. And it's not like it has to be done all at once. I'm also aware that as someone new to arch I'm not exactly in the position to make such suggestions, but anyway that's my attempt at a contribution.

Last edited by Belaros (2019-02-25 01:58:29)

Arch Linux

#1 2019-02-22 16:17:15

[Solved] Missing "libiconv.so.2", can't use makepkg.

#2 2019-02-22 16:19:46

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#3 2019-02-22 17:04:45

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#4 2019-02-22 18:18:52

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#5 2019-02-22 20:21:54

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#6 2019-02-23 01:25:52

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#7 2019-02-23 08:57:36

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#8 2019-02-24 20:17:35

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#9 2019-02-24 22:01:40

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#10 2019-02-24 22:09:45

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#11 2019-02-24 22:20:14

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#12 2019-02-24 22:25:54

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#13 2019-02-24 22:35:46

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#14 2019-02-24 23:12:43

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#15 2019-02-24 23:43:42

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#16 2019-02-24 23:58:57

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

#17 2019-02-25 01:22:14

Re: [Solved] Missing "libiconv.so.2", can't use makepkg.

Board footer