[users] vlc dependancy resolution error on EL6 (CentOS 6)

[Ljubomir Ljubojevic]

Hi. When I try to install vlc-1.1.11-1.el6.rf.x86_64 on CentOS 6 Error
popos up:

--> Finished Dependency Resolution
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libmodplug.so.0()(64bit)
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libupnp.so.3()(64bit)
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libthreadutil.so.2()(64bit)

Problem is that EPEL now has newer versions of libmodplug and libupnp
than repoforge.

My suggestion is to remove libmodplug and libupnp packages from EL6 repo
and recompile vlc with versions from EPEL.

If you do not want to compile agains EPEL, then please update libmodplug
and libupnp packages inside RepoForge repo.

Thanks

[Steve Huff]

Post by Ljubomir Ljubojevic
Problem is that EPEL now has newer versions of libmodplug and libupnp
than repoforge.
My suggestion is to remove libmodplug and libupnp packages from EL6 repo
and recompile vlc with versions from EPEL.
If you do not want to compile agains EPEL, then please update libmodplug
and libupnp packages inside RepoForge repo.

Ljubomir,

as a matter of policy, we avoid building packages that depend on other packages that are not available in the upstream distribution. we can look into upgrading libmodplug and libupnp; however, for the time being, i recommend that you either implement yum priorities (some good documentation is here: http://wiki.centos.org/PackageManagement/Yum/Priorities) or configure yum inclusions/exclusions.

-shuff
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20110904/7d353d88/attachment.bin

[Yury V. Zaytsev]

Post by Steve Huff
as a matter of policy, we avoid building packages that depend on other
packages that are not available in the upstream distribution. we can
look into upgrading libmodplug and libupnp;

I have recently updated libmodplug to be EPEL compatible, but Dag deemed
it to be too much of an effort to rebuild everything that depends on it
in the repo ;-(

The libupnp issue was so far unreported, but I am not very much
motivated to look into this if it's not going to be rebuilt anyway :-(

Maybe worth opening a ticket at github though...

[Ljubomir Ljubojevic]

Post by Yury V. Zaytsev

Post by Steve Huff
as a matter of policy, we avoid building packages that depend on other
packages that are not available in the upstream distribution. we can
look into upgrading libmodplug and libupnp;

I have recently updated libmodplug to be EPEL compatible, but Dag deemed
it to be too much of an effort to rebuild everything that depends on it
in the repo ;-(
The libupnp issue was so far unreported, but I am not very much
motivated to look into this if it's not going to be rebuilt anyway :-(
Maybe worth opening a ticket at github though...

First of all, this was reported in CentOS facebook group by one of the
members. I offered him workaround and then wrote original mail.

I have priorities in place, and EPEL is first below base repos. There is
no way I am going to step down from this approach. I actually mirror
and use some ~15 repositories (Repoforge has some 3-4, atrpms 3, etc.)
and beside that I also have my own repository.

I was hoping that finally RepoForge could be used as a default
complement to base repos and EPEL (absolute default in my opinion). I
guess I will have to do same thing I did for EL5 repos, select packages
from various repos into plnet-downloaded, and compile the rest by myself.

The idea is to form Desktop spinoff of CentOS 6. I spoke with KB very
shortly about this, and, in general, there is possibility to be
supported by CentOS project (more detailed conversation pending).
Spinoff would use Base and EPEL repos as a default, enlisting Fedora
maintainers to build conservative/stable versions of available fedora
packages, and then have "add-on" and "replace" repositories with
packages not supported by EPEL and/or with complicated dependency like
Audio/Video apps. The goal is not to have latest and greatest. I how be
content to have stable versions of desired apps on CentOS 6.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

I am currently busy reinstalling my main (Desktop) system with CentOS 6
and building all missing packages using src.rpms mostly from Fedora. So
far I have build and using following packages:

1 Firefox 6.0.1 from Remi
2 Thunderbird 6.0.1 from Remi
3 gnome-netstatus-2.28.1-1 Fedora (network applet - not NetworkManager)
4 Krusader 2.3.0 Fedora
5 MythTV 0.24.1 from RPMFusion (using stock QT but so far missing
mythweather )
6 libxklavier for Fedora (avoid crash of gnome-setting in NX session)
7 Wine 1.3.24-1 from Fedora

I also Accumulated packages like jre, VirtualBox, Skype, etc. into
"downloaded" repo so I do not have to install them manually.

This is why it would be nice if EPEL would be referenced when compiling
RepoForge. If that is not met, then I will have to revert to "build my
own" system.

Either way, I am appreciative of the work you are doing here.

[Bryan J Smith]

From: Ljubomir Ljubojevic <office at plnet.rs>

The idea is to form Desktop spinoff of CentOS 6.? I spoke with
KB very shortly about this, and, in general, there is possibility
to be supported by CentOS project (more detailed conversation
pending). Spinoff would use Base and EPEL repos as a default,
enlisting Fedora maintainers to build conservative/stable versions
of available fedora packages, and then have "add-on" and "replace"
repositories with packages not supported by EPEL and/or with
complicated dependency like Audio/Video apps.

But what happens when EL6 ages, much like EL5 has, and things from Fedora just don't build any more?? Now you're maintaining backports on things newer than EL, but older than Fedora.? You're starting yet a 3rd set of maintainers.

The goal is not to have latest and greatest. I how be content to
have stable versions of desired apps on CentOS 6.

Stable?? Define "stable"?

You're possibly not being able to leverage everything Fedora has because it just won't build on EL6 (let alone EL5 today).? And now you're newer than EL6.

I'm not trying to be devil's advocate.? I'm trying to speak from experience.? You're talking about having a 3rd set of maintainers between Fedora and EL.? That's a tall order.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

This argument has been made over the years.? Many of us who have bothered various Fedora maintainers or sent patches to them have run into, "it just won't build."? This is even starting to happen on EL6 now, as it's aging.

Again, it's a tall order, one that will keep increasing in burden.

Instead, I would recommend maintainers consider contributing their time and reviving the Fedora "Extended Support" concept, which is 3 release + 1 month.? That would push the maintenance of Fedora out to 19-21 months, instead of its current 13-15 month, typical lifecycle.? Just an idea.? ;)

[Bryan J Smith]

From: Ljubomir Ljubojevic <office at plnet.rs>

The idea is to form Desktop spinoff of CentOS 6.? I spoke with
KB very shortly about this, and, in general, there is possibility
to be supported by CentOS project (more detailed conversation
pending). Spinoff would use Base and EPEL repos as a default,
enlisting Fedora maintainers to build conservative/stable versions
of available fedora packages, and then have "add-on" and "replace"
repositories with packages not supported by EPEL and/or with
complicated dependency like Audio/Video apps.

But what happens when EL6 ages, much like EL5 has, and things from Fedora just don't build any more?? Now you're maintaining backports on things newer than EL, but older than Fedora.? You're starting yet a 3rd set of maintainers.

The goal is not to have latest and greatest. I how be content to
have stable versions of desired apps on CentOS 6.

Stable?? Define "stable"?

You're possibly not being able to leverage everything Fedora has because it just won't build on EL6 (let alone EL5 today).? And now you're newer than EL6.

I'm not trying to be devil's advocate.? I'm trying to speak from experience.? You're talking about having a 3rd set of maintainers between Fedora and EL.? That's a tall order.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

This argument has been made over the years.? Many of us who have bothered various Fedora maintainers or sent patches to them have run into, "it just won't build."? This is even starting to happen on EL6 now, as it's aging.

Again, it's a tall order, one that will keep increasing in burden.

Instead, I would recommend maintainers consider contributing their time and reviving the Fedora "Extended Support" concept, which is 3 release + 1 month.? That would push the maintenance of Fedora out to 19-21 months, instead of its current 13-15 month, typical lifecycle.? Just an idea.? ;)

[Bryan J Smith]

From: Ljubomir Ljubojevic <office at plnet.rs>

The idea is to form Desktop spinoff of CentOS 6.? I spoke with
KB very shortly about this, and, in general, there is possibility
to be supported by CentOS project (more detailed conversation
pending). Spinoff would use Base and EPEL repos as a default,
enlisting Fedora maintainers to build conservative/stable versions
of available fedora packages, and then have "add-on" and "replace"
repositories with packages not supported by EPEL and/or with
complicated dependency like Audio/Video apps.

But what happens when EL6 ages, much like EL5 has, and things from Fedora just don't build any more?? Now you're maintaining backports on things newer than EL, but older than Fedora.? You're starting yet a 3rd set of maintainers.

The goal is not to have latest and greatest. I how be content to
have stable versions of desired apps on CentOS 6.

Stable?? Define "stable"?

You're possibly not being able to leverage everything Fedora has because it just won't build on EL6 (let alone EL5 today).? And now you're newer than EL6.

I'm not trying to be devil's advocate.? I'm trying to speak from experience.? You're talking about having a 3rd set of maintainers between Fedora and EL.? That's a tall order.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

This argument has been made over the years.? Many of us who have bothered various Fedora maintainers or sent patches to them have run into, "it just won't build."? This is even starting to happen on EL6 now, as it's aging.

Again, it's a tall order, one that will keep increasing in burden.

Instead, I would recommend maintainers consider contributing their time and reviving the Fedora "Extended Support" concept, which is 3 release + 1 month.? That would push the maintenance of Fedora out to 19-21 months, instead of its current 13-15 month, typical lifecycle.? Just an idea.? ;)

[Bryan J Smith]

From: Ljubomir Ljubojevic <office at plnet.rs>

The idea is to form Desktop spinoff of CentOS 6.? I spoke with
KB very shortly about this, and, in general, there is possibility
to be supported by CentOS project (more detailed conversation
pending). Spinoff would use Base and EPEL repos as a default,
enlisting Fedora maintainers to build conservative/stable versions
of available fedora packages, and then have "add-on" and "replace"
repositories with packages not supported by EPEL and/or with
complicated dependency like Audio/Video apps.

But what happens when EL6 ages, much like EL5 has, and things from Fedora just don't build any more?? Now you're maintaining backports on things newer than EL, but older than Fedora.? You're starting yet a 3rd set of maintainers.

The goal is not to have latest and greatest. I how be content to
have stable versions of desired apps on CentOS 6.

Stable?? Define "stable"?

You're possibly not being able to leverage everything Fedora has because it just won't build on EL6 (let alone EL5 today).? And now you're newer than EL6.

I'm not trying to be devil's advocate.? I'm trying to speak from experience.? You're talking about having a 3rd set of maintainers between Fedora and EL.? That's a tall order.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

This argument has been made over the years.? Many of us who have bothered various Fedora maintainers or sent patches to them have run into, "it just won't build."? This is even starting to happen on EL6 now, as it's aging.

Again, it's a tall order, one that will keep increasing in burden.

Instead, I would recommend maintainers consider contributing their time and reviving the Fedora "Extended Support" concept, which is 3 release + 1 month.? That would push the maintenance of Fedora out to 19-21 months, instead of its current 13-15 month, typical lifecycle.? Just an idea.? ;)

[Ljubomir Ljubojevic]

Post by Yury V. Zaytsev

Post by Steve Huff
as a matter of policy, we avoid building packages that depend on other
packages that are not available in the upstream distribution. we can
look into upgrading libmodplug and libupnp;

I have recently updated libmodplug to be EPEL compatible, but Dag deemed
it to be too much of an effort to rebuild everything that depends on it
in the repo ;-(
The libupnp issue was so far unreported, but I am not very much
motivated to look into this if it's not going to be rebuilt anyway :-(
Maybe worth opening a ticket at github though...

First of all, this was reported in CentOS facebook group by one of the
members. I offered him workaround and then wrote original mail.

I have priorities in place, and EPEL is first below base repos. There is
no way I am going to step down from this approach. I actually mirror
and use some ~15 repositories (Repoforge has some 3-4, atrpms 3, etc.)
and beside that I also have my own repository.

I was hoping that finally RepoForge could be used as a default
complement to base repos and EPEL (absolute default in my opinion). I
guess I will have to do same thing I did for EL5 repos, select packages
from various repos into plnet-downloaded, and compile the rest by myself.

The idea is to form Desktop spinoff of CentOS 6. I spoke with KB very
shortly about this, and, in general, there is possibility to be
supported by CentOS project (more detailed conversation pending).
Spinoff would use Base and EPEL repos as a default, enlisting Fedora
maintainers to build conservative/stable versions of available fedora
packages, and then have "add-on" and "replace" repositories with
packages not supported by EPEL and/or with complicated dependency like
Audio/Video apps. The goal is not to have latest and greatest. I how be
content to have stable versions of desired apps on CentOS 6.

This could make CentOS/EL 6 very popular for desktop use, securing
stability. And if you take a look at the number of packages already in
Fedora, only waiting to be recompiled, you can not deny potential value
of EPEL and it's maintainers.

I am currently busy reinstalling my main (Desktop) system with CentOS 6
and building all missing packages using src.rpms mostly from Fedora. So
far I have build and using following packages:

1 Firefox 6.0.1 from Remi
2 Thunderbird 6.0.1 from Remi
3 gnome-netstatus-2.28.1-1 Fedora (network applet - not NetworkManager)
4 Krusader 2.3.0 Fedora
5 MythTV 0.24.1 from RPMFusion (using stock QT but so far missing
mythweather )
6 libxklavier for Fedora (avoid crash of gnome-setting in NX session)
7 Wine 1.3.24-1 from Fedora

I also Accumulated packages like jre, VirtualBox, Skype, etc. into
"downloaded" repo so I do not have to install them manually.

This is why it would be nice if EPEL would be referenced when compiling
RepoForge. If that is not met, then I will have to revert to "build my
own" system.

Either way, I am appreciative of the work you are doing here.

[Yury V. Zaytsev]

Post by Steve Huff
as a matter of policy, we avoid building packages that depend on other
packages that are not available in the upstream distribution. we can
look into upgrading libmodplug and libupnp;

I have recently updated libmodplug to be EPEL compatible, but Dag deemed
it to be too much of an effort to rebuild everything that depends on it
in the repo ;-(

The libupnp issue was so far unreported, but I am not very much
motivated to look into this if it's not going to be rebuilt anyway :-(

Maybe worth opening a ticket at github though...

[Ljubomir Ljubojevic]

Hi. When I try to install vlc-1.1.11-1.el6.rf.x86_64 on CentOS 6 Error
popos up:

--> Finished Dependency Resolution
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libmodplug.so.0()(64bit)
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libupnp.so.3()(64bit)
Error: Package: vlc-1.1.11-1.el6.rf.x86_64 (plc-repoforge)
Requires: libthreadutil.so.2()(64bit)

Problem is that EPEL now has newer versions of libmodplug and libupnp
than repoforge.

My suggestion is to remove libmodplug and libupnp packages from EL6 repo
and recompile vlc with versions from EPEL.

If you do not want to compile agains EPEL, then please update libmodplug
and libupnp packages inside RepoForge repo.

Thanks

[Steve Huff]

Post by Ljubomir Ljubojevic
Problem is that EPEL now has newer versions of libmodplug and libupnp
than repoforge.
My suggestion is to remove libmodplug and libupnp packages from EL6 repo
and recompile vlc with versions from EPEL.
If you do not want to compile agains EPEL, then please update libmodplug
and libupnp packages inside RepoForge repo.

Ljubomir,

as a matter of policy, we avoid building packages that depend on other packages that are not available in the upstream distribution. we can look into upgrading libmodplug and libupnp; however, for the time being, i recommend that you either implement yum priorities (some good documentation is here: http://wiki.centos.org/PackageManagement/Yum/Priorities) or configure yum inclusions/exclusions.

-shuff
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110904/7d353d88/attachment.sig>