Package Details: jre 23.0.1-1

Git Clone URL: https://aur.archlinux.org/jdk.git (read-only, click to copy)
Package Base: jdk
Description: Oracle Java Runtime Environment
Upstream URL: https://www.oracle.com/java/
Licenses: LicenseRef-custom
Conflicts: jdk
Provides: java-runtime, java-runtime-headless, java-runtime-headless-jdk, java-runtime-jdk23, jre23-jdk, jre23-jdk-headless
Submitter: td123
Maintainer: dbermond
Last Packager: dbermond
Votes: 1086
Popularity: 0.124319
First Submitted: 2011-08-27 17:56 (UTC)
Last Updated: 2024-11-16 14:08 (UTC)

Dependencies (12)

Required by (1730)

Sources (9)

Pinned Comments

dbermond commented on 2024-03-19 19:54 (UTC)

  • 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.

Latest Comments

« First ‹ Previous 1 .. 67 68 69 70 71 72 73 74 75 76 77 .. 81 Next › Last »

jjacky commented on 2012-04-27 15:48 (UTC)

Besides the little bug mentionned, I would suggest a couple of things (that could also be applied to jdk) : - use /tmp instead of $startdir as download location (to move the file from) - move the file in $startdir, and then create a symlink in src/ -- this would allow to easily keep the file in startdir, use the cleaning (that removes src/) and still be able to re-build the package without anything needed. Here's a PKGBUILD implementing this: https://gist.github.com/2510259

<deleted-account> commented on 2012-04-27 15:22 (UTC)

This is the fixed version: https://gist.github.com/2510111/de86a1b1602a8c62ebfdf1e51f07c550c46feeec

rtimush commented on 2012-04-27 14:59 (UTC)

7.4-1 doesn't pick up tar.gz stored in ~/Downloads because of double '~/' (jdk package does)

Det commented on 2012-04-27 13:50 (UTC)

7u4's here then. The user's gotta download the package himself for now. Guess the http://uni-smr.ac.ru guy(s) will pull it tomorrow or later today.

Det commented on 2012-04-17 11:53 (UTC)

You think Oracle cares? I like the 7.1/2 idea, though. Simpler than just stating the build number and better than raising the epoch.

davidovitch commented on 2012-04-17 10:32 (UTC)

From the pacman man page: Alphanumeric: 1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1 Numeric: 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0 Why does Oracle violates this principle by stating that 7 < 7u < 7u2 ? Maybe we need to convince them to follow a pacman compatible approach :-) Would a sensible alternative be 7 < 7.1u < 7.2u ? On the other hand, the jre7-openjdk version number also looks a bit archaic: 7.b147_2.1-3 (In case I am stating the obvious, apologies, I am trying to grasp how pacman judges what the newest version is)

Det commented on 2012-04-16 21:26 (UTC)

Yeah, that seriously sucks (pacman probably considers this thing to be some alpha/beta/pre version). I guess I could bump the epoch with the next update.

davidovitch commented on 2012-04-15 19:37 (UTC)

Maybe it's my ignorance, but it today I noticed that yaourt and pacman considered the new version number 7u3-1 as a downgrade compared to the previous 7-3, so it never got updated until I told so.

EasySly commented on 2012-04-06 21:48 (UTC)

Please note: Bug/FR for downloading files with some specific behavior was commited to https://bugs.archlinux.org/task/29316. You can vote for this or use patch to able to install jre6/jdk6 via AUR. This path also will fix the possible issue with jre/jdk if it will use oracle site. Thanks, Vladimir

« First ‹ Previous 1 .. 67 68 69 70 71 72 73 74 75 76 77 .. 81 Next › Last »