On Mon, 29 Nov 2004 02:54:53 -0600, Jeff Vian wrote: > On Mon, 2004-11-29 at 09:35 +0100, Michael Schwendt wrote: > > On Mon, 29 Nov 2004 01:14:08 -0600, Jeff Vian wrote: > > > > > As I see it, the packagers in charge of fedora.us (aka fedora-extras) > > > refuse to try and build packages that are cross compatible in spite of > > > Dag's attempts to work with them > > > > Where can I learn more about those attempts? > > > This is part of one thread on the subject. > http://www.redhat.com/archives/fedora-list/2004-November/msg00731.html There have not been any attempts since the fedora.us preparation talks on fedora-devel@xxxxxxxxx till early 2003. So, this is beating a dead horse. If you want cross compatibility, * you agree on common package naming guidelines, * you don't use conflicting versioning schemes, * you don't upgrade eachother at all, * you play nice with Fedora Core as a common base, i.e. you don't upgrade Fedora Core, regardless of how minor the upgrade may be (fedora.us discontinued its separate and very small "patches" repository a year ago), * you agree on moving overlapping content into a common base repository (Fedora Core is a base, Fedora Extras is the next candidate), * you replicate common packages if need be, so feature set and versions are the same in every repository (rebuilding packages creates a dependency on multiple build environments), * you coordinate updates with the packagers of all affected dependencies (this creates a need for pre-release QA!), * you open up your development process. Some items from the list would have been simple to do, though if you don't get people to agree on common versioning guidelines because of "explicit Epochs", everything is lost already. ;) Other items would not be feasible without a lot of overhead or without violating a repositories' goals. E.g. fedora.us is self-hosting except for its dependence on Fedora Core. Obviously, you can't have an open community project, with public pre-release QA policies, depend on packages which are published by an individual using a closed development process. Further, as soon as there are overlapping contents, either all repositories agree on using the same build and name-version-release of a package (which likely is too limiting for some repositories), or you no longer play nice with eachother. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3 loadavg: 1.29 1.12 1.09