[users] EPEL

[Lucian]

Hello,

Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

[Lucian]

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Hm, sent it too fast, should have used a more meaningful subject,
sorry about this.

[Rex Dieter]

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Feel free to poke me to help drive any changes required on EPEL side of
things.

-- Rex

[Lucian]

Post by Rex Dieter

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Feel free to poke me to help drive any changes required on EPEL side of
things.
-- Rex

Rex,

Is this EPEL's official position (because it sounds too good to be
true) on the matter?

[Orion Poplawski]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

[Lucian]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. ?But by the nature of divergent
development they are going to happen.

How do we fix divergent development?
Problem is EPEL has become the de-facto extra repo for EL, however one
cannot have a proper desktop/workstation without Dag/RF, but combining
them causes headaches which really should not exist, it's the only
major distro out there with this problem...
Personally I was hoping an EPEL compatible build of RPMfusion, which
didn't happen.

[Rex Dieter]

Post by Lucian

Post by Orion Poplawski

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. Identify where things are incompatible
2. work toward a mutually agreeable solution.

so let's start, got any concrete examples of 1?

-- rex

[Lucian]

Post by Lucian

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. ?But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. ?Identify where things are incompatible
2. ?work toward a mutually agreeable solution.
so let's start, got any concrete examples of 1?

Unfortuatelly yes:
http://pastie.org/2117283

[Rex Dieter]

Post by Lucian

Post by Rex Dieter

Post by Lucian

Post by Orion Poplawski

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. Identify where things are incompatible
2. work toward a mutually agreeable solution.
so let's start, got any concrete examples of 1?

http://pastie.org/2117283

Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

-- Rex

[Yury V. Zaytsev]

Post by Rex Dieter
Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

Hi Rex,

You are right, it has been suggested already, but I left this mail
unread for the lack of time. I have committed the updated SPEC (builds
fine on my mock builder), but it will take awhile for Dag to rebuild and
push things out.

Also, I noticed that you have bumped the epoch in your SPEC, but I guess
that as long as vlc is linked to a binary-compatible libmodplug your
library taking over ours shouldn't be a problem...

Thanks for following up,

[Steven L. Seed]

I was one that suggested it. Thanks for taking the time to make this
change. Is there are more appropriate channel to make these kinds of
requests in the future?

Post by Yury V. Zaytsev

Post by Rex Dieter
Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

Hi Rex,
You are right, it has been suggested already, but I left this mail
unread for the lack of time. I have committed the updated SPEC (builds
fine on my mock builder), but it will take awhile for Dag to rebuild and
push things out.
Also, I noticed that you have bumped the epoch in your SPEC, but I guess
that as long as vlc is linked to a binary-compatible libmodplug your
library taking over ours shouldn't be a problem...
Thanks for following up,

[Yury V. Zaytsev]

Post by Steven L. Seed
I was one that suggested it. Thanks for taking the time to make this
change. Is there are more appropriate channel to make these kinds of
requests in the future?

Hi!

If you are certain that you hit a bug or it's a package bump / rebuild
request you can file an issue at the tracker:

https://github.com/repoforge/rpms

Otherwise, posting to this list is perfectly appropriate. It's just a
matter of (the lack of) time to process these requests :-( as you
imagine my top priority are packages that I need for work.

[Yury V. Zaytsev]

Post by Steven L. Seed
I was one that suggested it. Thanks for taking the time to make this
change. Is there are more appropriate channel to make these kinds of
requests in the future?

Hi!

If you are certain that you hit a bug or it's a package bump / rebuild
request you can file an issue at the tracker:

https://github.com/repoforge/rpms

Otherwise, posting to this list is perfectly appropriate. It's just a
matter of (the lack of) time to process these requests :-( as you
imagine my top priority are packages that I need for work.

[Steven L. Seed]

I was one that suggested it. Thanks for taking the time to make this
change. Is there are more appropriate channel to make these kinds of
requests in the future?

Post by Yury V. Zaytsev

Post by Rex Dieter
Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

Hi Rex,
You are right, it has been suggested already, but I left this mail
unread for the lack of time. I have committed the updated SPEC (builds
fine on my mock builder), but it will take awhile for Dag to rebuild and
push things out.
Also, I noticed that you have bumped the epoch in your SPEC, but I guess
that as long as vlc is linked to a binary-compatible libmodplug your
library taking over ours shouldn't be a problem...
Thanks for following up,

[Yury V. Zaytsev]

Post by Rex Dieter
Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

Hi Rex,

You are right, it has been suggested already, but I left this mail
unread for the lack of time. I have committed the updated SPEC (builds
fine on my mock builder), but it will take awhile for Dag to rebuild and
push things out.

Also, I noticed that you have bumped the epoch in your SPEC, but I guess
that as long as vlc is linked to a binary-compatible libmodplug your
library taking over ours shouldn't be a problem...

Thanks for following up,

[Rex Dieter]

Post by Lucian

Post by Rex Dieter

Post by Lucian

Post by Orion Poplawski

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. Identify where things are incompatible
2. work toward a mutually agreeable solution.
so let's start, got any concrete examples of 1?

http://pastie.org/2117283

Yeah, the easiest solution there would be to upgrade libmodplug in rf,
which I believe had already been suggested (by someone?), but beyond
that, I'd not seen any sort of reply on that proposal.

-- Rex

[Lucian]

Post by Lucian

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. ?But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. ?Identify where things are incompatible
2. ?work toward a mutually agreeable solution.
so let's start, got any concrete examples of 1?

Unfortuatelly yes:
http://pastie.org/2117283

[Yury V. Zaytsev]

Post by Lucian
How do we fix divergent development?

This question is in a very same vein as asking why would we have 5 major
car platform manufacturers producing mutually incompatible products,
which results in the duplication of the engineering efforts instead of
having one worldwide meta-manufacturer, that would produce the most
advanced car platforms in a truly efficient way.

Do you have an answer for that already?

Post by Lucian
Problem is EPEL has become the de-facto extra repo for EL, however one
cannot have a proper desktop/workstation without Dag/RF, but combining
them causes headaches which really should not exist, it's the only
major distro out there with this problem...

It would be nice to have a meta-project or a VCS to share the SPEC files
in a much as it is possible, as well as to have some common packaging
guidelines etc., but this is a huge administrative and coordination
effort and we are all overly busy people...

Post by Lucian
Personally I was hoping an EPEL compatible build of RPMfusion, which
didn't happen.

Did you contribute to this happening in any form?

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

I don't think your irony is justified.

I am very sure that EPEL people are no more interested in intentionally
breaking the compatibility with other repositories to cause the trouble
to the users than we are.

[Rex Dieter]

Post by Lucian

Post by Orion Poplawski

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

How do we fix divergent development?

1. Identify where things are incompatible
2. work toward a mutually agreeable solution.

so let's start, got any concrete examples of 1?

-- rex

[Yury V. Zaytsev]

Post by Lucian
How do we fix divergent development?

This question is in a very same vein as asking why would we have 5 major
car platform manufacturers producing mutually incompatible products,
which results in the duplication of the engineering efforts instead of
having one worldwide meta-manufacturer, that would produce the most
advanced car platforms in a truly efficient way.

Do you have an answer for that already?

Post by Lucian
Problem is EPEL has become the de-facto extra repo for EL, however one
cannot have a proper desktop/workstation without Dag/RF, but combining
them causes headaches which really should not exist, it's the only
major distro out there with this problem...

It would be nice to have a meta-project or a VCS to share the SPEC files
in a much as it is possible, as well as to have some common packaging
guidelines etc., but this is a huge administrative and coordination
effort and we are all overly busy people...

Post by Lucian
Personally I was hoping an EPEL compatible build of RPMfusion, which
didn't happen.

Did you contribute to this happening in any form?

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

I don't think your irony is justified.

I am very sure that EPEL people are no more interested in intentionally
breaking the compatibility with other repositories to cause the trouble
to the users than we are.

[Lucian]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. ?But by the nature of divergent
development they are going to happen.

How do we fix divergent development?
Problem is EPEL has become the de-facto extra repo for EL, however one
cannot have a proper desktop/workstation without Dag/RF, but combining
them causes headaches which really should not exist, it's the only
major distro out there with this problem...
Personally I was hoping an EPEL compatible build of RPMfusion, which
didn't happen.

[Rex Dieter]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

http://fedoraproject.org/wiki/EPEL/FAQ#What_about_compatibility_with_other_third_party_repositories.3F

... The EPEL project encourages its maintainers to solve such problems
together with the maintainers from other repositories in order to find a
solution that is acceptable for both sides...

-- Rex

[Lucian]

Post by Rex Dieter

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

http://fedoraproject.org/wiki/EPEL/FAQ#What_about_compatibility_with_other_third_party_repositories.3F
... The EPEL project encourages its maintainers to solve such problems
together with the maintainers from other repositories in order to find a
solution that is acceptable for both sides...
-- Rex

Sounds nice in theory, in reality EPEL and RF have been coexisting
with conflicts for several years now.. :(

[Lucian]

Post by Rex Dieter

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

http://fedoraproject.org/wiki/EPEL/FAQ#What_about_compatibility_with_other_third_party_repositories.3F
... The EPEL project encourages its maintainers to solve such problems
together with the maintainers from other repositories in order to find a
solution that is acceptable for both sides...
-- Rex

Sounds nice in theory, in reality EPEL and RF have been coexisting
with conflicts for several years now.. :(

[Orion Poplawski]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

We do try to avoid conflicts when we can. But by the nature of divergent
development they are going to happen.

[Rex Dieter]

Post by Lucian
Is this EPEL's official position (because it sounds too good to be
true) on the matter?

http://fedoraproject.org/wiki/EPEL/FAQ#What_about_compatibility_with_other_third_party_repositories.3F

... The EPEL project encourages its maintainers to solve such problems
together with the maintainers from other repositories in order to find a
solution that is acceptable for both sides...

-- Rex

[Lucian]

Post by Rex Dieter

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Feel free to poke me to help drive any changes required on EPEL side of
things.
-- Rex

Rex,

Is this EPEL's official position (because it sounds too good to be
true) on the matter?

[Yury V. Zaytsev]

Post by Lucian
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

We are mostly not using EPEL ourselves, so obviously nobody was aware of
any recent compatibility problems. It is not surprising, however, that
they do exit, given the fact that there is some overlap (and nowadays
probably a considerable overlap) in the packages that we offer, whereas
there is no structured effort at this moment to pro-actively prevent
such conflicts.

Therefore, an essential step to fixing those would be to report them in
the first place. We are certainly not interested in breaking the
compatibility for the sake of it, so such reports would be dealt with on
a best-effort basis.

[Lucian]

Hello,

Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

[Lucian]

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Hm, sent it too fast, should have used a more meaningful subject,
sorry about this.

[Rex Dieter]

Post by Lucian
Hello,
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

Feel free to poke me to help drive any changes required on EPEL side of
things.

-- Rex

[Yury V. Zaytsev]

Post by Lucian
Currently there are some conflicts between EPEL and RF packages; is
there any intention on RF's part to correct whatever the problem is so
that the two repos do not conflict?

We are mostly not using EPEL ourselves, so obviously nobody was aware of
any recent compatibility problems. It is not surprising, however, that
they do exit, given the fact that there is some overlap (and nowadays
probably a considerable overlap) in the packages that we offer, whereas
there is no structured effort at this moment to pro-actively prevent
such conflicts.

Therefore, an essential step to fixing those would be to report them in
the first place. We are certainly not interested in breaking the
compatibility for the sake of it, so such reports would be dealt with on
a best-effort basis.