Hi Jiri,
Luckily (or not? - because it passed update test) this do not happen always. And unluckily this was bugged after the f19 freeze - https://bugzilla.redhat.com/show_bug.cgi?id=979128
I think I will abandon whole update alternatives process and come with direct remove/add as this is not firs time when alternatives behaved .. as they do. But until now it was always catch in time.
Please don't drop alternatives from OpenJDK. ;-)
But why is the bug marked as "CLOSED WORKSFORME"?
I think it's a real problem if a user installs/upgrade and can't run "java" out of the box.
Created bug #983677. Hope this time someone will fix the packages instead of closing without resolution.
[]s, Fernando Lozano
On 07/11/2013 10:14 AM, Fernando Lozano wrote:
But why is the bug marked as "CLOSED WORKSFORME"?
I've always considered that as a copout by somebody who isn't interested in fixing what they consider an insignificant bug. More than once I've had somebody ask for more, very specific information because they haven't been able to duplicate the issue.
On Thu, Jul 11, 2013 at 02:14:20PM -0300, Fernando Lozano wrote:
I think I will abandon whole update alternatives process and come with direct remove/add as this is not firs time when alternatives behaved .. as they do. But until now it was always catch in time.
Please don't drop alternatives from OpenJDK. ;-)
It's a really messy way to get the wanted result (swapable java stacks). I think we can do better. I'm not saying we should drop it before we have a better approach, but I think that should be the aim.
I always find
$ rpm -qf `which java` file /usr/bin/java is not owned by any package
to be very frustrating.
I think it's a real problem if a user installs/upgrade and can't run "java" out of the box.
Absolutely.
Matthew Miller wrote:
I always find
$ rpm -qf `which java` file /usr/bin/java is not owned by any package
to be very frustrating.
Ditto. I've been meaning to write a packaging draft to the alternatives guidelines to enforce the idea that packages MUST own their 'alternatives' targets
(Fwiw, I already do that in any alternatives-using package I maintain or contribute to)
-- rex
Hi,
I think I will abandon whole update alternatives process and come with direct remove/add as this is not firs time when alternatives behaved .. as they do. But until now it was always catch in time.
Please don't drop alternatives from OpenJDK. ;-)
It's a really messy way to get the wanted result (swapable java stacks). I think we can do better. (...)
I always find
$ rpm -qf `which java` file /usr/bin/java is not owned by any package
to be very frustrating.
We need a better which, that follow symlinks ? ;-)
I guess here the problem is with RPM. It won't allow the same file being owned by multipla packages.
Pardon if I'm talking about something you've already tried.
If you package a set of alternative configs as their own package, and make other Java packages depends on it? If I understand alternatives, it relies on symlinks that point to other symlinks. So the "top level" symlinks, like /usr/bin/java and /etc/alternatives/java, would be part of that java-alternatives package. Them the symlinks that point to real binaries would be owned by the specific jre or jdk package.
As anyone could install alternatives-java per se, it would have a dummy script that echoes "no default java selected" and exit an error code.
Am I being to simplicist?
[]s, Fernando Lozano
On Thu, 11 Jul 2013 12:54:36 -0500 Rex Dieter wrote:
$ rpm -qf `which java` file /usr/bin/java is not owned by any package
to be very frustrating.
Ditto. I've been meaning to write a packaging draft to the alternatives guidelines to enforce the idea that packages MUST own their 'alternatives' targets
But how can multiple packages trade ownership of the same file?
Maybe rpm -qf should follow symlinks to find the "real" file?
Once upon a time, Tom Horsley horsley1953@gmail.com said:
On Thu, 11 Jul 2013 12:54:36 -0500 Rex Dieter wrote:
Ditto. I've been meaning to write a packaging draft to the alternatives guidelines to enforce the idea that packages MUST own their 'alternatives' targets
But how can multiple packages trade ownership of the same file?
It isn't a file, it is a symlink, and all the packages should have the same symlink (pointing to /etc/alternatives). I'm pretty sure that rpm will allow multiple packages to own the same symlink (as long as they all have the same target). IMHO that would make things even easier to figure out; "rpm -qf /usr/bin/java" would list all the packages that can "claim" java.
On 07/11/2013 11:41 AM, Chris Adams wrote:
IMHO that would make things even easier to figure out; "rpm -qf /usr/bin/java" would list all the packages that can "claim" java.
Would it, or would it just find the first one and stop? I'm asking because I don't know enough about how rpm handles such things, although I do agree that it *should* work the way you say.
Once upon a time, Joe Zeff joe@zeff.us said:
On 07/11/2013 11:41 AM, Chris Adams wrote:
IMHO that would make things even easier to figure out; "rpm -qf /usr/bin/java" would list all the packages that can "claim" java.
Would it, or would it just find the first one and stop? I'm asking because I don't know enough about how rpm handles such things, although I do agree that it *should* work the way you say.
You can also have shared files, when the contents, ownership, and permissions on the files match, and rpm will list all matches. I can't think of an example off the top of my head, but I know I've seen it in the past.
Oh, one example is multilib (and I don't believe this behavior is multilib-specific):
$ rpm -qf /usr/share/doc/glibc-2*/README glibc-2.16-33.fc18.x86_64 glibc-2.16-33.fc18.i686
On Thu, 11 Jul 2013 14:09:26 -0500 Chris Adams wrote:
Oh, one example is multilib (and I don't believe this behavior is multilib-specific):
Oh but it is. Multilib is one gigantic undocumented screwup that exists only because someone wanted to avoid having to repackage everything in the universe to split it into common parts and arch specific parts.
On 07/11/2013 12:09 PM, Chris Adams wrote:
You can also have shared files, when the contents, ownership, and permissions on the files match, and rpm will list all matches. I can't think of an example off the top of my head, but I know I've seen it in the past.
Thank you. It's good to know that rpm will Do The Right Thing in cases like this.
On Thu, Jul 11, 2013 at 03:26:33PM -0400, Tom Horsley wrote:
Oh, one example is multilib (and I don't believe this behavior is multilib-specific):
Oh but it is. Multilib is one gigantic undocumented screwup
The specific thing in multilib is that the files can overlap without being identical. In perfectly normal RPM, two packages can own an identical file as long as it is actually bit-for-bit identical. (This is, of course, fragile when there's an update to one package but not the others.)
that exists only because someone wanted to avoid having to repackage everything in the universe to split it into common parts and arch specific parts.
That seems like a completely awesome thing to avoid.
On Thu, 11 Jul 2013 15:48:15 -0400 Matthew Miller wrote:
The specific thing in multilib is that the files can overlap without being identical. In perfectly normal RPM, two packages can own an identical file as long as it is actually bit-for-bit identical. (This is, of course, fragile when there's an update to one package but not the others.)
Then why, in Fedora 18, did yum start giving fatal errors and refuse to install packages that tried to create the same directory? (Which is why I suspect there are a gazillion rpms named "something-filesystem-something.rpm" that just create directories for other rpms to install into.)
That seems like a completely awesome thing to avoid.
Avoiding reflecting actual reality is a good thing?
Once upon a time, Tom Horsley horsley1953@gmail.com said:
Then why, in Fedora 18, did yum start giving fatal errors and refuse to install packages that tried to create the same directory? (Which is why I suspect there are a gazillion rpms named "something-filesystem-something.rpm" that just create directories for other rpms to install into.)
I think directories are different, especially since it is difficult (at best) in an automated buildsystem to create them with the same timestamp (which is part of what RPM evaluates for determining if items are the "same").
In the past, a bunch of directories just went un-owned, but that caused other problems, so there was a push to get them all owned. Some multilib packages took the separate-RPM approach.
I'd hardly call 24 *-filesystem-*.rpm packages "a gazillion" though. :)
Am 11.07.2013 21:26, schrieb Tom Horsley:
On Thu, 11 Jul 2013 14:09:26 -0500 Chris Adams wrote:
Oh, one example is multilib (and I don't believe this behavior is multilib-specific):
Oh but it is. Multilib is one gigantic undocumented screwup that exists only because someone wanted to avoid having to repackage everything in the universe to split it into common parts and arch specific parts.
no - arch independent things are apcked in .noarch subpackages
multilib exists that you can run things like Skype, wine and whatever i686 software on top of a x86_64 system
Am 11.07.2013 22:51, schrieb Tom Horsley:
On Thu, 11 Jul 2013 15:48:15 -0400 Matthew Miller wrote:
The specific thing in multilib is that the files can overlap without being identical. In perfectly normal RPM, two packages can own an identical file as long as it is actually bit-for-bit identical. (This is, of course, fragile when there's an update to one package but not the others.)
Then why, in Fedora 18, did yum start giving fatal errors and refuse to install packages that tried to create the same directory?
because identical files means also *any* attribute and permissions/owners/groups have to be identical
On 07/11/2013 08:41 PM, Chris Adams wrote:
Once upon a time, Tom Horsley horsley1953@gmail.com said:
On Thu, 11 Jul 2013 12:54:36 -0500 Rex Dieter wrote:
Ditto. I've been meaning to write a packaging draft to the alternatives guidelines to enforce the idea that packages MUST own their 'alternatives' targets
But how can multiple packages trade ownership of the same file?
It isn't a file, it is a symlink, and all the packages should have the same symlink (pointing to /etc/alternatives).
Almost.
These alternatives-symlinks are created post-install, i.e. rpm doesn't know about them.
This allows %ghost-ing them, i.e. letting rpm know about the fact these symlinks are present, while the contents of these files/symlinks is not known to rpm.
In other words, the java rpms could use something along the lines of this:
%files %ghost /usr/bin/java
%post [...] /usr/sbin/alternatives --install /usr/bin/java [...] [...]
I am using this approach, e.g. Coin2-devel to handle /usr/bin/coin-config, which may point to different versions of "config-scripts".
Ralf
Chris Adams wrote:
Once upon a time, Tom Horsley horsley1953@gmail.com said:
On Thu, 11 Jul 2013 12:54:36 -0500 Rex Dieter wrote:
Ditto. I've been meaning to write a packaging draft to the alternatives guidelines to enforce the idea that packages MUST own their 'alternatives' targets
But how can multiple packages trade ownership of the same file?
It isn't a file, it is a symlink, and all the packages should have the same symlink (pointing to /etc/alternatives). I'm pretty sure that rpm will allow multiple packages to own the same symlink (as long as they all have the same target). IMHO that would make things even easier to figure out; "rpm -qf /usr/bin/java" would list all the packages that can "claim" java.
yup, neat it would be. :)
-- rex
On 07/11/2013 07:14 PM, Fernando Lozano wrote:
Hi Jiri,
Luckily (or not? - because it passed update test) this do not happen always. And unluckily this was bugged after the f19 freeze - https://bugzilla.redhat.com/show_bug.cgi?id=979128
I think I will abandon whole update alternatives process and come with direct remove/add as this is not firs time when alternatives behaved .. as they do. But until now it was always catch in time.
Please don't drop alternatives from OpenJDK. ;-)
Dont worry. No pure removal:)
But why is the bug marked as "CLOSED WORKSFORME"?
Well I guess the manual setup of alternatives was enough for Gil.
But I agree with your tracking bug (Thank you). I will fix soon.
I think it's a real problem if a user installs/upgrade and can't run "java" out of the box.
Created bug #983677. Hope this time someone will fix the packages instead of closing without resolution.
J.