Arch Linux User Repository

• Important notice:

As was made with the java packages in the official repositories, jdk now provides the jre alongside it, and both packages conflict with each other. During the package upgrade to version 22, act accordingly to your needs. For example, if you have both jdk and jre installed, only jdk will be sufficient, as it now also contains the runtime environment, and jre can be uninstalled. If you have only jre installed, no action is required.

Yeah, that makes a lot more sense. I added a $SRCDEST support, but since $XDG_DOWNLOAD_DIR is seemingly only set after running 'xdg-user-dirs-update' (and even then it points to $HOME/Downloads by default), I'm not gonna bother with it unless somebody starts complaining. The PKGBUILD is already fat as shit.

> Not really following you there. > > 1) $SRCDEST is for makepkg-downloaded sources, right? Does anybody actually download their other stuff in there? I prefer to store all the sources in one place and it's annoying to have to copy the source back to the location where I downloaded it the first time when I rebuild a package. Since the source is not in the source array, makepkg does not look for the source in SRCDEST anymore on its own. > 2) It's simpler to have the source in the same directory for rebuilds. Why would you wanna symlink it e.g. from your desktop? I usually remove the old package directory, but like to keep the source for the case of pkgrel increments. It doesn't matter if it is a symlink or a regular file in srcdir, but the source should be kept in its original location. > 3) Also is that the same thing with $XDG_DOWNLOAD_DIR? Because I don't have any power over where the user's gonna download the source with his browser. Afaik, that's the default download location for firefox and chrome/-ium.

@sjakub, I did the file name thing you mentioned. The re-request thing _I_ mentioned proved to be easy as hell by using an until loop. Bash is actually a pretty nice language for things like this.

Well, libsaproc.so and libattach.so (located in /opt/java/jre/lib/$_arch, not /lib) are both jdk files so that's still quite interesting.

D'oh, I'm getting mixed up. The one I installed last night must have been jre, which goes through a very similar process (and the handling is the same since you maintain both). It was the one that was throwing the errors, which it said had to do with versioning conflicts. I think one of the ones it had me remove was libattach.so? I can't remember, as it was late and I didn't pay it much attention.

Well, it's not .rpm, as I'm also already mentioning the tarball thing ("[...] download the tarball (.tar.gz) yourself"). The arch thing is sort of matter of opinion. It's pretty easy to just do `uname -m`, but of course even easier not to. I'll think it over. I'll probably also make the user-intervention part to re-ask for the tarball if it wasn't found, instead of just ending the build. E: Also, sorry about getting a bit defensive there the last time. I figured you thought it was all my fault, when you mentioned the manual download. Actually, it seems like heftig was the only one who did. E2: @palintropos, no, you don't have to apologize, if you have a genuine problem. But the thing is that I don't understand any of it. First of, this package doesn't install _anything_ to /lib and I can't think of a single case when an error would instruct you to remove something from there. About the second issue, you either downloaded a wrong package (e.g. jre, not jdk) or you really just don't have it there.

I'm sorry to have to come back with a problem, and have no intention of rescinding my compliment, but some things do appear to be wrong. For instance, I had to manually delete two .so files from /lib. That wasn't difficult and it told me which two (an error, not the install script), but couldn't the installer do that? Furthermore, once I removed those and followed the instructions, it seemed to update fine. However, when I did a full update again, jdk came up as needing to be upgraded, and it no longer finds the file even if I place it in the correct directory in /tmp.

Yes, I do realize the license requirement. And that's not your fault, just Oracle's stupidity :/ The file name - it's possible to figure that out, but since the script knows the name it's looking for why doesn't it just display it? It could be rpm, and if you're dealing with several machines with different archs you have to stop and think which one it is. All of that could be avoided by adding that name to the message.