> 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. Actually, how do we know what builds and validates in RF and what doesn't? You should rather trigger a global SRPMS rebuild and... whatever fails to build should go to /dev/null! Take the example of RF's Comix package. I dunno how have you built the RPM, because the SRPM won't build no matter what I tried! (I even suspected that someone has built Comix on a Fedora box, and since the binary seemed to work on CentOS/EL too...) In my view, a repo should be consistent, and its own SRPMS should only need the official EL clone repo to build, or whatever is agreed to be a required dependency (e.g. Fusion declaratively requires EPEL, and even my tiny repo requires or *might* require EPEL for *some* dependencies). If a SRPMS builds under CentOS 5.0 and it doesn't under 5.3, then this package is broekn. I am sorry to decline your offer: I don't need access to a 8,000-package repo, for later I could be accused of some breakage I might have not caused. Unless RF starts from zero (that is, by tossing whatever does not build), I am not interested: better not touch it. Otherwise, everyone is free to rebuild from: http://odiecolon.lastdot.org/el5/SRPMS/ If it doesn't work... c'est la vie. This is the first time in my life that I've built RPMs, so... > It was maintained by matthias in the past, and he > left. I could remove the packages, but that would not > help. Oh yes, it would. Instead of many broken packages, better fewer, but self-containing/self-consistent. > > 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. This is the problem with a 8,000-package repo. Hey, even RHEL has only 2,400 or whatever they have! > Should I rebuild it just because EPEL upgraded their > libraries ? Will EPEL fix the compatibility with the > clamav package, a conflict they introduced ? That's a delicate question. > 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. Umm... so let me get it straight (yes, I can be very mean): you *update* or *add* new packages instead of fixing the broken ones? Isn't this approach more like... Ubuntu's? > An automated buildsystem that would rebuild all dependencies > would be great, I don't have it though. Moi non plus. > 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 ? Because a repo should be consistent. It should be able to rebuild from its own SRPMS. Whatever doesn't fit the picture should go to /dev/null. > What is the difference between a package that cannot be > installed, and a package that is not available ? The same as the difference between "honey, I wanted to cheat on you, but I couldn't find anyone willing to fsck with me" and "honey, this temptation never existed for me"! It's peace of mind. "Now, let's see if this package is broken or not.... oh, it's not broken." But seriously, it's not 5%. If a SRPM doesn't build, then it's broken. This way you could very well have 20% of breakage, in real terms. You know, in the F/LOSS world the idea is that the sources be available *and* that they would build. > Everyone expects it to be fixed. Just delete the packages that don't rebuild. Then, maybe someone will get involved. > 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. Whatever I could fix and build and I was interested in, would normally get into my tiny repo. SRPMs available. > Then do something about it. Instead of a consumer (and > complainer), become a producer (and contributor). VLC and MPlayer have so many dependencies, that my nerves just broke. Really. I wanted to build them, but then... > 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 :-) Well, I don't have such a strong belief in any repo, the same way I have zero belief in God. > let my users down because there is no real upgrade path > (the fact that you > for some reason need RPMforge is the proof). That's cute. Indeed, I *need* RF, despite all the "defamatory" howto/disclaimer on how I use my repo with EPEL and only enable RF for a few things, etc. > But don't expect me (or dries, christoph, fabian, ...) to > fix it because that simply *does* *not* *scale*. 7,600 packages is really too much for a couple of people to maintain. Unless it's scaled *down*... Regards, R-C __________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/