10:26 p.m.
i noticed my gnucash would not run after today's yum update.
i ran gnucash from the terminal and it complained:
--
gnucash-bin: error while loading shared libraries: libgtkhtml-3.8.so.15:
cannot open shared object file: No such file or directory
--
so i checked the yum.log:
--
...
Apr 10 19:08:29 Updated: gtkhtml3.i386 3.14.1-1.fc7
Apr 10 19:12:23 Erased: gtkhtml38
...
--
i reinstalled gtkhtml38 and gnucash works again.
5:17 a.m.
On Tue, 10 Apr 2007 22:26:44 -0500, Eric L wrote:
i noticed my gnucash would not run after today's yum update.
i ran gnucash from the terminal and it complained:
--
gnucash-bin: error while loading shared libraries: libgtkhtml-3.8.so.15:
cannot open shared object file: No such file or directory
--
so i checked the yum.log:
--
...
Apr 10 19:08:29 Updated: gtkhtml3.i386 3.14.1-1.fc7
Apr 10 19:12:23 Erased: gtkhtml38
...
--
i reinstalled gtkhtml38 and gnucash works again.
Please file a bug report about gtkhtml38 in Extras. It contains:
Provides: gtkhtml3 = %{version}-%{release}
which is wrong, since that enables gtkhtml3 to update it.
See https://bugzilla.redhat.com/111071 for the RPM background.
2:50 p.m.
Michael Schwendt (mschwendt.tmp0701.nospam(a)arcor.de) said:
Please file a bug report about gtkhtml38 in Extras. It contains:
Provides: gtkhtml3 = %{version}-%{release}
which is wrong, since that enables gtkhtml3 to update it.
See https://bugzilla.redhat.com/111071 for the RPM background.
Essentially, you're saying that any package which requires a versioned
API should, rather than having a build requirement on the package,
should have a build *file* requirement on either one of the include
files, or the pkg-config file. Because, well, the package that provides
it might have a name change.
Is that *seriously* what you're suggesting?
Bill
3:34 p.m.
On Wed, 11 Apr 2007 15:50:23 -0400, Bill Nottingham wrote:
Michael Schwendt said:
> Please file a bug report about gtkhtml38 in Extras. It contains:
>
> Provides: gtkhtml3 = %{version}-%{release}
>
> which is wrong, since that enables gtkhtml3 to update it.
> See https://bugzilla.redhat.com/111071 for the RPM background.
Essentially, you're saying that any package which requires a versioned
API should, rather than having a build requirement on the package,
should have a build *file* requirement on either one of the include
files, or the pkg-config file. Because, well, the package that provides
it might have a name change.
Is that *seriously* what you're suggesting?
Bill
Where do you see such a suggestion?
All I've pointed out is that two lines in your spec file are the culprit
and broke the user's system.
1) The gtkhtml38 package "Provides: gtkhtml3 = %version-%release",
and due to that, installing a newer gtkhtml3 EVR _removes_ gtkhtml38.
2) The gtkhtml38-devel package also "Provides: gtkhtml3 = %version-%release",
which is just a typo, but causes the same problem.
Fix RPM if you don't like it. Bug 111071 is where I've reported the
questionable behaviour in rpm after I had found it with "gpgme" and
"gpgme03" at fedora.us. Jeff Johnson's reply: NOTABUG
Have you read that bug yet?
Why do you flame me (also in bug 236009)?
3:36 p.m.
Michael Schwendt (mschwendt.tmp0701.nospam(a)arcor.de) said:
> Essentially, you're saying that any package which requires a
versioned
> API should, rather than having a build requirement on the package,
> should have a build *file* requirement on either one of the include
> files, or the pkg-config file. Because, well, the package that provides
> it might have a name change.
>
> Is that *seriously* what you're suggesting?
Where do you see such a suggestion?
It's the logical conclusion. If:
1) the package providing the new capability can't Provide: the old
version of the package
2) you don't want to have to change requiring packages in the case
of such a move
... the only solution left is file deps. I suppose you could have
magic gtkhtml(abi)-3.8 provides or something. But that's just
as odd.
Why do you flame me (also in bug 236009)?
It's not you personally. I just find the fact that there is *no* way
to perform such an upgrade without either a) changing all requiring
packages b) modifying them to use file requirements to be a bad
solution.
But, eh. rpm broken, film at 11.
Bill
3:58 p.m.
On Wed, 11 Apr 2007 16:36:26 -0400, Bill Nottingham wrote:
Michael Schwendt said:
> > Essentially, you're saying that any package which requires a versioned
> > API should, rather than having a build requirement on the package,
> > should have a build *file* requirement on either one of the include
> > files, or the pkg-config file. Because, well, the package that provides
> > it might have a name change.
> >
> > Is that *seriously* what you're suggesting?
>
> Where do you see such a suggestion?
It's the logical conclusion.
And the conclusion is false, because I've not suggested anything
as a replacement for the Provides or BuildRequires.
I've told you what doesn't work anymore nowadays. We've had gpgme03
"Provides: gpgme = 0.3.something", too, and a similar thing in other
packages in the past, until rpm broke it.
Btw, from your gnucash spec:
# for gtkhtml3-devel
BuildRequires: /usr/include/libgtkhtml-3.8/gtkhtml/gtkhtml.h
A change on "Tue Mar 13 2007".
But, eh. rpm broken, film at 11.
Bill
Right. I'm innocent. ;)
3:59 p.m.
Michael Schwendt (mschwendt.tmp0701.nospam(a)arcor.de) said:
> > Where do you see such a suggestion?
>
> It's the logical conclusion.
And the conclusion is false, because I've not suggested anything
as a replacement for the Provides or BuildRequires.
I'm not saying *YOU* suggested it, but by saying that what's currently
there is broken, file requirements is the logical conclusion.
Btw, from your gnucash spec:
# for gtkhtml3-devel
BuildRequires: /usr/include/libgtkhtml-3.8/gtkhtml/gtkhtml.h
A change on "Tue Mar 13 2007".
Yep. I control that package, so I can easily change it. The idea
is that other packages don't need changed.
Bill
6249
days inactive
6249
days old
6 comments
3 participants
participants (3)
-
Bill Nottingham -
Eric L -
Michael Schwendt