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/
On Mon, Jun 29, 2009 at 03:57:09PM -0700, Radu-Cristian FOTESCU wrote:
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.
Following this line of thought no new people would ever join, let's say, the GCC development team, unless the GCC project starts from scratch. Luckily, this is far from being the case. And yes, GCC underwent quite a few changes from v2 to v3 and v4, changes that broke things along their path and, finally, led to the great compiler we have today. The same would hold for any large project (the kernel, firefox, etc.)
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...
[...]
You know, in the F/LOSS world the idea is that the sources be available *and* that they would build.
If your repo is in the F/LOSS world, then in your view it should rebuild flawlessly, forever. "C'est la vie" is out of question.
Fortunately, the way F/LOSS works is: the source is there, please contribute. The only thing certain is that anyone who cares can put spare time into it, with the best of intentions and that new contributions cannot be kept out.
You may be *entitled* to demand quality from the products you *buy*, but that's an entirely different thing.
Whatever I could fix and build and I was interested in, would normally get into my tiny repo. SRPMs available.
Good luck. I fail to see why tens of micro repos are easier to maintain consistent than a large one. Besides, they will have a grand total of tens of people involved, which would definitely solve the next issue:
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*...
...or scale the maintainers up.
Cheers,
Mihai
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 -
Mihai T. Lazarescu -
Radu-Cristian FOTESCU