[users] Issue With Updated "libmodplug" Package

[Alan Bartlett]

Hi Folks,

Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

[ajb at Duo2 ~]$ uname -r
2.6.32-131.6.1.el6.x86_64
[ajb at Duo2 ~]$ sudo yum check-update
<snip>
libmodplug.x86_64
0.8.8.3-1.el6.rf
rpmforge
[ajb at Duo2 ~]$ sudo yum update
<snip>
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libmodplug.x86_64 0:0.8.7-1.el6.rf will be updated
--> Processing Dependency: libmodplug.so.0()(64bit) for package:
gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
---> Package libmodplug.x86_64 0:0.8.8.3-1.el6.rf will be an update
--> Finished Dependency Resolution
Error: Package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64 (@rpmforge)
Requires: libmodplug.so.0()(64bit)
Removing: libmodplug-0.8.7-1.el6.rf.x86_64 (@rpmforge)
libmodplug.so.0()(64bit)
Updated By: libmodplug-0.8.8.3-1.el6.rf.x86_64 (rpmforge)
Not found
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$ sudo rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$

Is there anything you would like me to test, to help you resolve this issue?

Regards,
Alan.

[Yury V. Zaytsev]

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

[Valery Mitsyn]

Post by Yury V. Zaytsev

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

vlc, xine-lib also suffer from libmodplug update.

And I have exactly the same problem on SL4 (el4).

Hmmm, since libmodplug still is in the old version on SL5 (el5),
would it will be updated on that plapform too?

[Dag Wieers]

Post by Valery Mitsyn

Post by Yury V. Zaytsev

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

vlc, xine-lib also suffer from libmodplug update.
And I have exactly the same problem on SL4 (el4).
Hmmm, since libmodplug still is in the old version on SL5 (el5),
would it will be updated on that plapform too?

Yes, the libmodplug library should not be updated without taking into
account all the packages that are affected. I reverted that package (and
would like to address this with the other packagers).

The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

[Yury V. Zaytsev]

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Isn't it just a couple of rebuilds that is necessary?

I didn't expect anything to fail to build since the version update
didn't seem to have changes in the API.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Isn't it just a couple of rebuilds that is necessary?
I didn't expect anything to fail to build since the version update
didn't seem to have changes in the API.

The soname changed, that usually is a sign the ABI is not compatible and
therefor it is not just a drop-in replacement. And yes, rebuilding all the
packages that make use of it could be possible. The question is, do we
really want this, just for this library update ?

In the past we only considered to update multimedia libraries when there
was a major rebuild going to happen for one or more multimedia
applications anyway. Often because they needed it.

That said, maybe there is a compelling reason for updating libmodplug
(like it causes crashes even for people not needing it, or there is a
security risk with the older version). In that case the effort to
rebuild may very well be required.

[Yury V. Zaytsev]

Post by Dag Wieers
The soname changed, that usually is a sign the ABI is not compatible and
therefor it is not just a drop-in replacement. And yes, rebuilding all the
packages that make use of it could be possible. The question is, do we
really want this, just for this library update ?

It didn't look too bad to me, but you as a person that actually does the
builds might have a different opinion on that ;-)

Post by Dag Wieers
That said, maybe there is a compelling reason for updating libmodplug
(like it causes crashes even for people not needing it, or there is a
security risk with the older version). In that case the effort to
rebuild may very well be required.

The point of the libmodplug update was to fix the compatibility with
EPEL, because they are building their stuff against the latest version
of libmodplug and the still have stuff built against the old one, so
people were having problems because of this...

[Yury V. Zaytsev]

Post by Dag Wieers
The soname changed, that usually is a sign the ABI is not compatible and
therefor it is not just a drop-in replacement. And yes, rebuilding all the
packages that make use of it could be possible. The question is, do we
really want this, just for this library update ?

It didn't look too bad to me, but you as a person that actually does the
builds might have a different opinion on that ;-)

Post by Dag Wieers
That said, maybe there is a compelling reason for updating libmodplug
(like it causes crashes even for people not needing it, or there is a
security risk with the older version). In that case the effort to
rebuild may very well be required.

The point of the libmodplug update was to fix the compatibility with
EPEL, because they are building their stuff against the latest version
of libmodplug and the still have stuff built against the old one, so
people were having problems because of this...

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Isn't it just a couple of rebuilds that is necessary?
I didn't expect anything to fail to build since the version update
didn't seem to have changes in the API.

The soname changed, that usually is a sign the ABI is not compatible and
therefor it is not just a drop-in replacement. And yes, rebuilding all the
packages that make use of it could be possible. The question is, do we
really want this, just for this library update ?

In the past we only considered to update multimedia libraries when there
was a major rebuild going to happen for one or more multimedia
applications anyway. Often because they needed it.

That said, maybe there is a compelling reason for updating libmodplug
(like it causes crashes even for people not needing it, or there is a
security risk with the older version). In that case the effort to
rebuild may very well be required.

[Ljubomir Ljubojevic]

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Is it feasible to create an app that would analyze and populate the
package dependency tree, so developers can have clear overview of
rebuild implications?

[Yury V. Zaytsev]

Post by Ljubomir Ljubojevic
Is it feasible to create an app that would analyze and populate the
package dependency tree, so developers can have clear overview of
rebuild implications?

It's as easy as grep the SPEC tree for files that contain the library
name in question in the BuildRequires.

[Yury V. Zaytsev]

Post by Ljubomir Ljubojevic
Is it feasible to create an app that would analyze and populate the
package dependency tree, so developers can have clear overview of
rebuild implications?

It's as easy as grep the SPEC tree for files that contain the library
name in question in the BuildRequires.

[Yury V. Zaytsev]

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Isn't it just a couple of rebuilds that is necessary?

I didn't expect anything to fail to build since the version update
didn't seem to have changes in the API.

[Ljubomir Ljubojevic]

Post by Dag Wieers
The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

Is it feasible to create an app that would analyze and populate the
package dependency tree, so developers can have clear overview of
rebuild implications?

[Dag Wieers]

Post by Valery Mitsyn

Post by Yury V. Zaytsev

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

vlc, xine-lib also suffer from libmodplug update.
And I have exactly the same problem on SL4 (el4).
Hmmm, since libmodplug still is in the old version on SL5 (el5),
would it will be updated on that plapform too?

Yes, the libmodplug library should not be updated without taking into
account all the packages that are affected. I reverted that package (and
would like to address this with the other packagers).

The multimedia-libraries are a complex case where one change can lead you
into a dark alley without knowing where it leads to :-/

[Valery Mitsyn]

Post by Yury V. Zaytsev

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

vlc, xine-lib also suffer from libmodplug update.

And I have exactly the same problem on SL4 (el4).

Hmmm, since libmodplug still is in the old version on SL5 (el5),
would it will be updated on that plapform too?

[Alan Bartlett]

Post by Alan Bartlett
Hi Folks,
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.
[ajb at Duo2 ~]$ uname -r
2.6.32-131.6.1.el6.x86_64
[ajb at Duo2 ~]$ sudo yum check-update
<snip>
libmodplug.x86_64
? ?0.8.8.3-1.el6.rf
? ? ? rpmforge
[ajb at Duo2 ~]$ sudo yum update
<snip>
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libmodplug.x86_64 0:0.8.7-1.el6.rf will be updated
gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
---> Package libmodplug.x86_64 0:0.8.8.3-1.el6.rf will be an update
--> Finished Dependency Resolution
? ? ? ? ? Requires: libmodplug.so.0()(64bit)
? ? ? ? ? ? ? libmodplug.so.0()(64bit)
? ? ? ? ? Updated By: libmodplug-0.8.8.3-1.el6.rf.x86_64 (rpmforge)
? ? ? ? ? ? ? Not found
?You could try using --skip-broken to work around the problem
?You could try running: rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$ sudo rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$
Is there anything you would like me to test, to help you resolve this issue?
Regards,
Alan.

Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Alan.

[Yury V. Zaytsev]

Post by Alan Bartlett
Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Yes, because Dag was not convinced it's worth rebuilding the players
that depend on it... He didn't make up his mind on my last plea yet.

I have filled an issue at Github, so that it won't get forgotten:

https://github.com/repoforge/rpms/issues/20

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Alan Bartlett
Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Yes, because Dag was not convinced it's worth rebuilding the players
that depend on it... He didn't make up his mind on my last plea yet.
https://github.com/repoforge/rpms/issues/20

Thanks Yury.

Often the simplest answer is all that the end-user needs to read. :)

Alan.
(An end-user of Repoforge.)

[Alan Bartlett]

Post by Yury V. Zaytsev

Post by Alan Bartlett
Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Yes, because Dag was not convinced it's worth rebuilding the players
that depend on it... He didn't make up his mind on my last plea yet.
https://github.com/repoforge/rpms/issues/20

Thanks Yury.

Often the simplest answer is all that the end-user needs to read. :)

Alan.
(An end-user of Repoforge.)

[Yury V. Zaytsev]

Post by Alan Bartlett
Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Yes, because Dag was not convinced it's worth rebuilding the players
that depend on it... He didn't make up his mind on my last plea yet.

I have filled an issue at Github, so that it won't get forgotten:

https://github.com/repoforge/rpms/issues/20

[Alan Bartlett]

Hi Folks,

Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

[ajb at Duo2 ~]$ uname -r
2.6.32-131.6.1.el6.x86_64
[ajb at Duo2 ~]$ sudo yum check-update
<snip>
libmodplug.x86_64
0.8.8.3-1.el6.rf
rpmforge
[ajb at Duo2 ~]$ sudo yum update
<snip>
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libmodplug.x86_64 0:0.8.7-1.el6.rf will be updated
--> Processing Dependency: libmodplug.so.0()(64bit) for package:
gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
---> Package libmodplug.x86_64 0:0.8.8.3-1.el6.rf will be an update
--> Finished Dependency Resolution
Error: Package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64 (@rpmforge)
Requires: libmodplug.so.0()(64bit)
Removing: libmodplug-0.8.7-1.el6.rf.x86_64 (@rpmforge)
libmodplug.so.0()(64bit)
Updated By: libmodplug-0.8.8.3-1.el6.rf.x86_64 (rpmforge)
Not found
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$ sudo rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$

Is there anything you would like me to test, to help you resolve this issue?

Regards,
Alan.

[Yury V. Zaytsev]

Post by Alan Bartlett
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.

Dag, could you please re-build gstreamer-plugins-bad as it's still built
against older libmodplug?

[Alan Bartlett]

Post by Alan Bartlett
Hi Folks,
Earlier today, on my pure 64-bit RHEL 6.1 system, I noticed that there
were some updates from repoforge. All updates, bar one, applied
cleanly.
[ajb at Duo2 ~]$ uname -r
2.6.32-131.6.1.el6.x86_64
[ajb at Duo2 ~]$ sudo yum check-update
<snip>
libmodplug.x86_64
? ?0.8.8.3-1.el6.rf
? ? ? rpmforge
[ajb at Duo2 ~]$ sudo yum update
<snip>
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libmodplug.x86_64 0:0.8.7-1.el6.rf will be updated
gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
---> Package libmodplug.x86_64 0:0.8.8.3-1.el6.rf will be an update
--> Finished Dependency Resolution
? ? ? ? ? Requires: libmodplug.so.0()(64bit)
? ? ? ? ? ? ? libmodplug.so.0()(64bit)
? ? ? ? ? Updated By: libmodplug-0.8.8.3-1.el6.rf.x86_64 (rpmforge)
? ? ? ? ? ? ? Not found
?You could try using --skip-broken to work around the problem
?You could try running: rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$ sudo rpm -Va --nofiles --nodigest
[ajb at Duo2 ~]$
Is there anything you would like me to test, to help you resolve this issue?
Regards,
Alan.

Just checking. Has the libmodplug-0.8.8.3-1.el6.rf.x86_64 package been
pulled and is libmodplug-0.8.7-1.el6.rf.x86_64 the current version?

Alan.