-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote:
|>| message based on any other sources? We have June 2005, and I'm tired of |>| Feel free to travel back in time and dig deep in |>| the various list archives. |> |>I don't have a horse in this race, but since you ask: |> |>http://www.fedora.us/wiki/RepositoryMixingProblems | | A very old page. But doesn't matter.
I "felt free".
|>''Coordination among two or more repositories for compatibility would be |>far too difficult and incur much greater overhead. Updates would often |>involve multiple repository owners working in coordinated development |>and simultaneous publishing in order to prevent user breakage. This is a |>huge amount of extra development overhead.'' | | That is correct. Do you think it's wrong? If so, why?
Because -->
|>However the RPMforge folks appear to be four repos cooperating. | | No. Four people. Each of them runs an own repository, originally with | overlapping and conflicting content. What they are working on is ... | Now with regard to cooperation, what is written in above paragraph is very | true, particularly if you keep scalability in mind (number of developers, | number of packages and number of inter-package dependencies). The problem | of cooperation gets worse if you try to increase the number of separately | controlled repositories, which shall depend on eachother or depend on the | same base packages.
It seems there should be a technical solution for this if the will to encourage cooperation as the way forward is there.
| The phrase "all _possible_ packages" excludes the _impossible_ packages, | of course. ;)
It seems people external to the Redhat orbit resist the impossibility of mplayer, mp3 etc and the packages do exist.
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
| Have you ever before thought about how exactly collaboration between | multiple repositories could work? If so, care to share some thoughts?
Yeah. Have you thought about extending RPM? I did some work on the Busybox version of RPM a few months back. How about extending the granularity of versioning by header tokens that represent the patch level of the sources inside the RPM, eg, CAN numbers, and ./configure switches used, etc. Then when presented with an alleged update from another repo, it is possible for the rpmlibs to assess what is meant to have been updated compared to the currently installed package, perhaps from another repo, and so choose to not install it if nothing is actually updated compared to the installed version. Every time the RPM is rebased on new upstream versions the (bulk of) the patch info goes away with the patches. Put another way, make the currently human-only changelog stuff machine-readable.
Whatever other arguments that can be fielded against this idea, it won't break anything since the headers will be ignored by stuff that doesn't understand it.
- -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCoBX9jKeDCxMJCTIRAmWvAKCS3yJGN1iIMSJLrQ+U4SflPNhUJwCgk7fm a1d8r3quBeUqGbSq3qWyw00= =DqSu -----END PGP SIGNATURE-----
