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 proces
Chris Adams wrote:
> Once upon a time, Tom Horsley 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
On 07/11/2013 08:41 PM, Chris Adams wrote:
Once upon a time, Tom Horsley 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
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-fo
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 wa
Once upon a time, Tom Horsley 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
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
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
identi
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 tha
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 univer
Once upon a time, Joe Zeff 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
> becaus
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 suc
Once upon a time, Tom Horsley 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
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
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 r
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'
t
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 altern
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 informati
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
Hi there,
This is a minor bug, but a big annoyance for anyone who
uses java on Fedora. Latter I try to register on Fedora Project bug
track.
I saw the same issue on two diferent systems: one upgraded from
F17 to F19 via fedup, another installed clean from live media. Both had
yum -y update
20 matches
Mail list logo
