On 03/04/2010 04:28 PM, Adam Williamson wrote:
> On Thu, 2010-03-04 at 16:19 -0500, Peter Jones wrote:
>
>>> yup, this is very likely. One reason Mandriva's backports repository
>>> was initiated was because, when MDV allowed only conservative
>>> updates and had no official facility for adventurous updates, a
>>> forest of third-party repos offering new versions of things sprung
>>> up. Obviously this led to confusion for people doing user support
>>> ('wait, exactly *whose* KDE 4.3 packages were you running again?')
>>> and all> sorts of fun with incompatibilities between the third party
>>> repos.
>>
>> Just playing devil's advocate here - what's the virtue of trying to
>> avoid separate repos? It seems like there's a false dichotomy (trichotomy?)
>> going on here, where our choices are:
>>
>> 1) this is in the main Fedora(tm) repo
>> 2) we have a special repo for updates vs upgrades, each against stable
>> 3) A free for all of third party repos hosted at various different
>> places with huge conflicts and no coöperation whatsoever. Repos
>> everywhere, dogs and cats living together, Cain has been marked
>> and kicked out of the garden, total chaos.
>>
>> As a little gedankenexperiment, let's explore for a second a 4th option:
>> Fedora-blessed/hosted/sponsored/whatever repos for things that we don't
>> feel should be mandated on users, but which some users may want and some
>> maintainers want to be able to provide. A little bit of all three -
>> including a built-in need to be minimalist in construction, so as to
>> avoid conflict nightmares, but at the same time freedom to say "here's
>> a new major version of this, since we _know_ that's what you're looking
>> for if you've got this repo enabled".
>>
>> Obviously this would require some tools work, but isn't it worth
>> considering?
>
> What does option 4 provide over option 2?
>
> In fact, how is it even functionally different? 'Fedora' repositories
> are effectively nothing more than 'blessed' repositories anyway, given
> the considerable powers granted to maintainers.
Option two is one more repo for all "updates". Which may be well and
good, but might also be less interesting than a more general approach. In
#4, what I'm suggesting is essentially the possibility of a SIG having
overlay repos for whatever distro version(s) they want; they could be
experimental, they could be for upgrades that don't conform to a more
strict update policy, it could be for things even *I* haven't thought of
yet ;)
--
Peter
Old MacDonald had an agricultural real-estate tax abatement.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
