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 at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]