On Mon, 29 Jun 2009, Radu-Cristian FOTESCU wrote:
>
>> (1) I expect now patches from you to make a workable
>> audacious based on our audacious package. Apparently
>> you have the interest and the time to do it ?
>
> RF's audacious has unmet dependencies. It's as simple as that.
> It lacks audacious-plugins.
I am still waiting for it. I am willing to give you commit access to fix
all the things that irritate you. I offered the same to others.
If you wonder why I did not fix it myself, because I lack the time and
interest to fix it. It was maintained by matthias in the past, and he
left. I could remove the packages, but that would not help.
At least now if someone wants to install it, they can see it does not work
and may offer a fix. Nobody did until now, maybe you can change it.
If not, no harm done, it stays the same until I find the time and nothing
else to do. Which will not happen very soon though.
Believe me, I am not sitting here waiting for a new task to complete. But
if someone else has some time to help I can give you the authority to fix
it and you get my respect for it too :)
>> (2) No, they are not compatible, we know. Share to
>> help with this too ?
>> You first have to convince the Fedora
>> people that they will not
>> introduce new incompatibilities before starting.
>
> Nay. Please read again how my tiny repo tries to "fix/hack"
> the 4 libs from EPEL that break RF's MPlayer and VLC.
>
> Should the Fedora people be insensitive, what prevents you
> from just "suck in" the newer libdvdread, libdvdnav, libcaca
> and lzo from EPEL and just rebuild RF's VLC and MPlayer?
I recommend you to go and try do it and see how much else depends on these
and what no longer builds because of it and how much time you end up
spending for something that doesn't do more than before eventually if you
make it work.
Should I rebuild it just because EPEL upgraded their libraries ? Will EPEL
fix the compatibility with the clamav package, a conflict they introduced ?
> Because, honestly, a good deal of people only need the
> MPlayer+VLC+gstream stuff from RF. My understanding is
> that RF is so huge that it's very hard to manage, but...
> I'm afraid I have to say it's quite a "static" repo
> which doesn't try to rebuild anything!
RPMforge has about 20 to 30 new commits every week, and we do update lots
of packages regularly. The hard ones we may not do unless there is a
compelling reason and it still compiles against older distributions.
Again, I wouldn't mind if you send me patches to update something, but
believe me it is more than a simple update of the version. An automated
buildsystem that would rebuild all dependencies would be great, I don't
have it though.
>> Shall I simply stop doing RPMforge ?
>
> Hopefully not, *but* how about 400 rock-solid packages
> in RF instead of 8,000 packages with: some abandoned; some
> broken; etc.?
We have those 400 rock solid packages, even more than that. I'd say less
than 5% are in a bad shape. And audacious is probaby one of the more
visible ones. But again, why do you expect me to fix them, when you have
a need for it ?
What is the difference between a package that cannot be installed, and a
package that is not available ?
The first is easier to fix than the second. The problem is that nobody
offered a fix. Everyone expects it to be fixed.
>> Is that the position you prefer to force me into ?
>> Because I certainly did not force you into using
>> the repository.
>
> Nobody is trying to force anyone into anything. It just
> happens that your repo is the only one to offer VLC, for
> instance. And I personally needed a quick & dirty hack to
> accommodate RF with EPEL. That's all.
Fine, but then stop demanding something to be fixed, because you're
talking about the little free time I have. Send me a fix, or even better
offer to fix it yourself.
>> I don't know even why you want to use RPMforge, there must
>> be something that is missing from EPEL ?
>
> Yes. Let me state again:
> yum --enablerepo=rpmforge install gstreamer-plugins-bad gstreamer-plugins-ugly gstreamer-ffmpeg
> yum --enablerepo=rpmforge install mplayer mplayer-fonts mplayer-skins mplayerplug-in smplayer
> yum --enablerepo=rpmforge install vlc
>
> That's all I need from VLC. Dozens of multimedia dependent packages
> though. Some of them legally unsuitable for EPEL.
>
> And RPM Fusion doesn't even have VLC.
Then do something about it. Instead of a consumer (and complainer), become
a producer (and contributor).
>> I am happy to learn what you want to do though, because it
>> is easy to criticize, but it takes time to do some work.
>
> I know, and I understand that you are now vexed, but, like I said:
> instead of 8,000 packages in RF, better have 400 rock-solid ones?
We have maybe 7600 solid ones (in fact I don't think we have 8000
packages).
>> (And I hope the solution is not another repository, because
>> we have been there :-))
>
> The solution is *always* another repo. Why do you believe there are
> so many Linux distros? Are they really NEEDED? Nope. They're more
> than 3-4 distros because people can NOT cooperate properly, and
> their quick fix is to fork and whatnot.
The difference is that you can only install one distribution, but you can
install tons of incompatible repositories.
And the believe that one repo will rule them all (which is what Fedora and
EPEL wants you to believe) is just debunked by yourself above :-)
The most important reason I still have RPMforge is because I don't want to
let my users down because there is no real upgrade path (the fact that you
for some reason need RPMforge is the proof).
If the last user wants to turn off the light, then I know I can start
doing something else ;-)
PS To be honest, we could use some more people that want to help, if
something is missing or not being maintained, offer to maintain it !
But don't expect me (or dries, christoph, fabian, ...) to fix it because
that simply *does* *not* *scale*.
PS2 I discussed with christoph to set up a proper project management
system that would encourage collaboration more. But we don't need more
bugs, we need more people to help fix bugs, really.
--
-- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
