Selective Updates

[Orcan Ogetbil]

On Tue, May 4, 2010 at 5:26 PM, Jesse Keating wrote:
> On Tue, 2010-05-04 at 15:20 -0400, Bernd Stramm wrote:
>> On Tue, 04 May 2010 20:42:18 +0200
>> Kevin Kofler wrote:
>>
>> > Bernd Stramm wrote:
>> > > I would like to pick the packages that I'm adventurous with.
>> > > Currently that's not very easy, either an adventurousness level is
>> > > enabled in the repos or it isn't.  That means my package manager
>> > > gives me a flood of updates that I don't want. It would be nice to
>> > > be able to filter that. For my objective, that is a package
>> > > management issue, fedora policy doesn't need to be changed.
>> >
>> > What you're asking for is selective updating. This is a very hard
>> > problem to solve in practice, and in general unsolvable with a single
>> > repo. It is just impossible, with a single repository, to be able to
>> > select one type of changes without also accepting unrelated changes.
>> > Packages depend on each other, the same package receives changes of
>> > varying nature etc. So I am afraid what you're asking for is
>> > technically not possible, sorry.
>> >
>>
>> Yes I'm asking for selective updates, I know that. That is a hard
>> problem, I know. But it is not impossible.
>>
>> If the current package management tools don't make it possible, then
>> the tools can be improved.
>>
>> This may not be a goal that packaging people want to address at this
>> time, that's fine. But it is not impossible, particularly when you
>> consider that the users of selective updates are being adventurous on
>> purpose.
>>
>
> To make this happen, we'd have to maintain multiple branches of each
> package within each release, one branch just for the bugfixes, one
> branch just for the security fixes, one branch for the enhancements.
> Then we'd have to publish multiple updates repos for each release,
> segregated by what type of update builds go into it, so at any time
> there may be 4 versions of a given package floating around, the GA
> version, the latest security update version, the latest bugfix version,
> and the latest new upstream enhancement version.
>
> That represents a significant increase in load on developers, build
> systems, testers, and even users.  It's not that what you as for is
> impossible, its that the work required to produce it is difficult and
> too costly.
>

How about a de-centralized approach: main repo gets only critical
fixes. Releng will be responsible only for this repo.
Other than this, every major SIG gets their own update repo. They can
choose to (but are not required to) be compatible with other SIG's
update repo. Once every 6 months they merge best of what they have to
the main branch. Users, after installing Fedora, can get to choose
what updates repos they want to enable that are compatible.

It's kind of like Linus' git idea. Is this worse than the current 1
centralized repo approach? In theory, it automatically ends the
adventurous/conservative updates debate.

Orcan