-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Schwendt wrote:
Hi Michael -
|>I don't know how to read that page except as a statement that you will
|>not be cooperating with other repos
|
| Now you're jumping back and forth between different interpretations of the
| page. ;)
What was my alternative interpretation I just jumped from?
| Further, let me emphasise that with regard to individual packages there is
| no "you", but only _individual project contributors_, who have the freedom
| to decide on their own whether to collaborate and coordinate their
| packaging with whoever they want to. There is no rule, no policy
| whatsoever that collaboration would not be permitted, never attempted or
| won't ever be done.
Sure. Microsoft sing a similar song ("but you can download third-party
competitor apps") when people complain about "enabled by default on OS
install" features like WMP: they know a lot of people will not bother.
The Fedora imprimatur IS an important feature of Extras that WILL affect
uptake of Extras alone and elevate it above the other repos. Further
distance will be created between this newly elevated Extras and other
repos by the well-meaning and accurate advice: "oooh, better not put
those other repos in your yum.repos.d/ because they might be
incompatible with Extras". So despite Extras not being evil, it will
chill other repos. I'm not telling you that is your fault, I am just
observing it will happen.
Over time, because (base+extras) is the new base, the problems will
likely reduce, since repos like Dag intend compatability with Fedora base.
| However, as soon as somebody spends some time on analysing what kind of
| coordination would be necessary to solve inter-repository mixing problems
Seems to me RPM should be asked to deal with some or all of these
problems if possible.
|>unless they "submit" packages to you.
|
| I fail to find that on the page. The bottom part of the page suggests
| that users of independent package providers should encourage them to join
''So rather than adding other repositories to your apt/yum configuration
just because Fedora does not have the packages you want, please do the
following:
Encourage the independent packager to submit their packages to Fedora
QA. After package improvement, QA testing and some security
verification, their package can be in the Fedora tree. The original
packager gains the support of other Fedora developers, Bugzilla and
other infrastructure to raise the level of quality and compatibility of
submitted packages.''
That was the only way I saw on the page you would work with the
[previously] "independent packager". However I note some willingness
further down in your last mail.
| The most basic cooperation between multiple repositories would be to
| eliminate over-lapping content. That is, replicate common packages between
| all repositories participating in the cooperation, so package "foo" is the
| same (exactly the same!) in all repositories which provide it. It can
| be seen easily how much overhead this would create for N>1 package
| developers at Fedora Extras trying to coordinate upgrades/changes with 1
| external repository maintainer.
Yes, there is no point having multiple sources of the same package if
there is no disagreement about the build environment. If there is
disagreement, eg, different ./configure flags or patchlevels, then it
would be desirable to be able to transparently switch between
differently-compiled and/or differently composed/patched source versions
of the same package from the same or different repos.
| not done. Fedora Extras is treated as _the_ primary base repository after
| Fedora Core, which can be built upon. It is focused on these two. External
| package providers are welcome to offer add-ons on top of Core+Extras. And
Yeah, as I wrote before (base+extras) is the new base. Again the effect
is to pull packages from the RPMForge orbit into Extras, which because
of its "enabled by default" feature and Fedora relationship is likely to
become the uber-repo that you envisage.
| in case an external repository, which depends on Core+Extras, needs
| software versions newer than what is provided in Extras, that would be a
| scenario for coordination attempts with focus on not breaking Extras. A
| way of "upgrade first, then deal with the wreckage" is not something
| anyone at Fedora Extras will like.
It's encouraging that "Cooperation is possible" then... but this is new
information to me.
|>|>| 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?
|>|
|>| An extended/enhanced RPM is _not_ something we have at the moment. It's
|>| not something that was available when Fedora at fedora.us was discussed.
|>| It's not ready. Hence it doesn't solve any problem. It doesn't
remove the
|>| need for fine-grained packaging policies either, which extend up to the
|>| spec-file level.
|>
|>What kind of policies are we talking about here? Since everyone at
|>least agrees to be compatible with Fedora base, maybe these problems too
|>are open to a technical solution.
|
| Policies about everything that would ensure that package "foo" in
| repository X is fully compatible with repository Y.
Is there a URL with a canonical list anywhere?
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCpw+9jKeDCxMJCTIRAqpYAJ4j3l9rHV7vFkjRm/innMa9hFy8mwCeIXLD
lRlXHBwknR98kU/QS1GocKs=
=2vAc
-----END PGP SIGNATURE-----
