It might be nice if pacman would suggest newer packages when necessary. For example, I had to explicitly install jre7- and jdk7- openjdk to replace openjdk6 instead of just doing `pacman -Syu`. One might unknowingly miss such updates, thinking pacman would automatically install the latest upstream version.
Perhaps, in situations like this, pacman can ask something like the following.
Replace openjdk6 with jdk7-openjdk and jre7-openjdk? [Y/N]
What are your thoughts on such a feature?
Last edited by amadar (2012-10-24 23:15:37)
They only conflict with each other, they don't replace each other possibly because they're not compatible (look at the 'Provides' line - it's different).
Using a different example: python2 and python3 don't conflict with each other and you can have them both installed.
Last edited by karol (2012-10-24 23:20:59)
I noticed that about the 'provides' line. The package openjdk6 provides "java-environment=6 java-runtime=6 java-runtime-headless=6" whereas to provide those same three things with Java7 you now need three packages instead of just one: jdk7-openjdk, jre7-openjdk, and jre7-openjdk-headless. Those three packages provide java-environment=7, java-runtime=7, and java-runtime-headless=7, respectively.
The behavior I'm suggesting would be for pacman to recognize scenarios like in this case where one package can be "replaced" by three packages. But I don't mean Replaced in pacman's sense of the word. What I mean is that Java7 is the newest Java and so we move from Java6 to Java7 so that's what I mean by those three packages "replace" openjdk6.
I was noticing this scenario because since Arch is a rolling release distro where packages are kept bleeding edge, it seems like asking the user to "replace" openjdk6 with jre7- and jdk7- packages would be appropriate.
What's your opinion on that?
Last edited by amadar (2012-10-25 01:09:48)
That sounds very confusing since normally when pacman asks that, the replacement will replace the old package.
Surely you would at least need to use a different question in this sort of case? And to restrict it to packages explicitly installed.
Not doing what you suggest leaves the user with choice. Choice is precious, some of the times.
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
I'd expect that once our devs stop supporting Java 6, the Java 7 packages might prompt to replace Java 6. There's no sense in doing so now, when Java 6 is still supported.
Good opinions; perhaps my suggestion for pacman's prompt wasn't worded the right way.
So, when there's a package like openjdk6 which provides java-environment=6, java-runtime=6, and java-runtime-headless=6, maybe pacman should automatically prompt the user if he/she wishes to upgrade to the newer package(s) that provide the same but newer 'Provides' (e.g. the new jdk7 and jre7 packages provide java-environment=7, etc).
I think that would be a valid thing for pacman to do when new packages are released that provide the same Provides as older packages but of a newer version.
By simply doing 'pacman -Syu', I wouldn't know that java7 is released for the entire duration that java6 remains supported (supposing I don't manually stay up to date). On the other hand, it'd be nice and helpful for pacman to make the suggestion to install the newer package set because that would also conveniently notify the user of the new release.
So if package foo privides x=2, y=2, abd z=2, then the packages fu, bar, and baz are released and provide x=3, y=3, abd z=3, my suggestion is for pacman to ask if the user would like to replace foo with the three packages fu, bar, and baz despite the fact that foo is still supported. Pacman could also say something like "Your choice will be remembered until newer packages are released or the current package is dropped."
Do you get what I mean? What do you think?
Last edited by amadar (2012-10-26 21:23:34)