Selective Updates

[Bernd Stramm]

On Tue, 04 May 2010 14:26:34 -0700
Jesse Keating <jkeating at redhat.com> wrote:

> On Tue, 2010-05-04 at 15:20 -0400, Bernd Stramm wrote:
> > On Tue, 04 May 2010 20:42:18 +0200
> > Kevin Kofler <kevin.kofler at chello.at> 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.
> > 
> > Bernd
> > 
> > 
> > 
> > -- 
> > Bernd Stramm
> > <bernd.stramm at gmail.com>
> > 
> 
> 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.

Too costly with the current tools, I have no doubt. The method you
describe doesn't look manageable, you're right.

Perhaps I should go research packaging systems and strategies, there
may be demand for more customizable systems. This is basically the same
problem as people generating their own spins.

I was thinking about filtering the updates suggested by the current
system. That is more or less what someone has to do manually today if
they want to experiment with advanced versions of a particular package.

Bernd

-- 
Bernd Stramm
<bernd.stramm at gmail.com>