Eric S. Raymond wrote:
http://www.fedora.us/wiki/RepositoryMixingProblems Due to these reasons fedora.us has always said that we will not coordinate with external repositories. We never have these package clashes, and our package quality is on the average better. The drawback here is slower package review and publication.
The bigger drawback is that you don't have an extras repository at all! It sounds like you may be allowing unattained perfection to become the enemy of the good.
Huh?
fedora.us is all about providing add-ons for Red Hat Linux, and now Fedora Core. (Well and also now Legacy, community developed security backport update packages for the older distributions.)
(1) Software compromised for IP reasons must be exiled to livna.org Repository keepers must agree to comply with a ban list compiled by Red Hat.
It already seems to have happened. It seems that rpm.livna.org is collaborative with a Bugzilla and QA procedure too.
Good, that's a forward step.
And they seem to be using the exact same QA procedure that fedora.us uses.
I doubt you'd get any pushback on these requirements. And the cost of QA-monitoring these repositories would undoubtedly be lower than the cost of building and maintaining one big repository of your own. You'd win fairly big on the download costs alone.
We respectfully disagree with this line of thinking.
OK, that's your call to make and not mine. Axel Thimm's post and yours come together to make it clear that I've inadvertently walked into the middle of a political issue. That's not where I want to be.
Unfortunately this is true of our current situation.
What I do want is a well-defined procedure by which I can drop (for example) fetchmail point releases into an "official" repository and have them available for people to apt-get.
apt-get may be a problem, given that there is great resistance within RH to including apt-get within FC. That resistance is weakening though. Resistance is futile. <evil grin>
There used to be seemingly good arguments against apt... like the use of --nodeps (which truly was not a problem). But now the latest apt uses native rpmlib, so that argument is gone. There are also benefits like this (quoting Panu Matilainen):
I have experienced yum being EXTREMELY SLOW compared to apt when calculating a huge amount of dependencies, for example.
Indeed. Just calculating the dependencies of RH 9 -> FC 1 upgrade (no actual upgrade done, all headers, pkglists etc local) on my PIII 500Mhz testbox takes apt: 10 seconds yum: ~50 *minutes*
http://linux.duke.edu/projects/metadata/readme.metadata Fortunately though rpm-metadata is in the process of standardizing, and that will further reduce resistance to including apt since the same mirrors will work for apt, yum, or up2date. The question now is if apt and the other clients will have it fully implemented in time for FC2 inclusion. HELP THEM!!!
ESR wrote:
Things I don't care about:
- what the repository is called
- who runs it
- whether it takes RPMs I build or builds its own from metadata and
tarballs that I drop there.
This is good.
Things I do care about:
- It must be generally accepted as authoritative for people running Fedora.
It is already clearly understood that fedora.us will become Fedora Extras at some point.
- It must not require me to do hand-work for each release (that means it can't have an unscriptable web-only interface)
You have to solve this problem sometime, because there are about 500,000 developers out there with similar needs. I'm willing to build client tools like the fedora-submit and bugzilla-submit scripts I've already done to assist the effort.
My greatest concern here is that I question the efficacy of any such client. I can see how a XML-RPC client can used a template based approach in submitting new packages within a new Bugzilla report, or submitting a package update to an existing Bugzilla report, but otherwise I don't see it being very useful.
https://bugzilla.fedora.us/show_bug.cgi?id=520 Something like how I started this Bugzilla report is one way packages are submitted. Only the URL to SRPM, URL to md5sums.asc, and a short description about what the package does. A tool that can do this reliably would save maybe 30-45 seconds. It would easy to use that same tool to post updates to that package in the existing report too. Beyond this what would the tool do that is useful?
In the future fedora.redhat.com will allow CVS access with ACL's for certain developers to apply updates directly to CVS for both tracking and build source purposes. My current proposal is to do both this and one report per package publication for tracking the discussion necessary to bring each package to publication status. The procedure for submission, testing, approval and publication would be similar to what fedora.us is currently doing, except much more automated, with a few approval steps by managers along the way.
Currently FC is not using any Bugzilla tracking for each updates-testing, and this is a bit disconcerting for the community developers and users alike. This direction that we are heading will hopefully improve this situation.
Warren