On Mon, 29 Jun 2009, Radu-Cristian FOTESCU wrote: > >> 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! What was the problem with audacious again ? > 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...) We publish buildlogs. There is no reason to find it out yourself. I also do not build from the SRPM, I build from the SPEC file directly, so if an SRPM is published, it is because it build fine. I hate to first create an SRPM just to build the package, because RPM was great because you'd only get an SRPM if the package build fine. The Fedora people turned this the other way around when their buildsystem started from SRPMs. > 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). Oh, I agree completely. So when are you going to help us? Because everytime you say what your wish is, it feels as if you are asking me to do it and I already said I don't have the time for it. > If a SRPMS builds under CentOS 5.0 and it doesn't under 5.3, > then this package is broekn. Ok, you're making it yourself very hard now, but I will accept scripts/tools that can verify this. I don't think any other repository is even doing this though. > 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. That's a strange position. So you complain because you see the flaws, but you only want to help when there are no flaws and in fact there is nothing to fix. > 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... Wait. So you blame me for all these things that you don't care about for your own repository ? :-) So I can fix this by simply saying: If it doesn't work... c'est la vie. So there you have it, all is well now :) > 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? If it doesn't work... c'est la vie ! >> 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. If it doesn't work... c'est la vie !! > 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. Can you give me an example of an SRPM that doesn't build. Because we have buildlogs of everything, so everything at least once build. I don't see the point in trying to rebuild everything for RHEL5.3, RHEL5.4. > You know, in the F/LOSS world the idea is that the sources be > available *and* that they would build. If it doesn't work... c'est la vie !!! (I am getting used to it now :)) >> 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... So you are just lazy and you want me to do your dirty work, unless it is something simple, then you do it yourself. Regardless you prefer to complain :) >> 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*... It is not. Everything that works, works. The things that do not work, can be fixed. I don't want to remove things that can be fixed because recreating a package from scratch is harder than fixing one that used to work. But until now I only know that audacious does not work. And you didn't offer to fix it. I haven't heard of any other. Did you say 7600 packages failed ? Can you please list them. I like statistics. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]