On Tue, 04 May 2010 21:08:23 -0400
Matt McCutchen wrote:
> On Tue, 2010-05-04 at 17:44 -0400, Bernd Stramm wrote:
> > 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
On Tue, 2010-05-04 at 17:44 -0400, Bernd Stramm wrote:
> 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
On Wed, 2010-05-05 at 00:16 +0200, Kevin Kofler wrote:
> Nor can you really stop us from closing all bugs filed
> against the conservative official repo as WONTFIX with a comment of "fixed
> in kde-redhat stable, please use that".
If that practice became a problem, it would be escalated through
Jesse Keating wrote:
> On Tue, 2010-05-04 at 17:44 -0400, Orcan Ogetbil wrote:
>> 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 ar
nges 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.
> >> >
> >>
&g
On Tue, 2010-05-04 at 17:44 -0400, Bernd Stramm wrote:
>
> 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.
That assumes that the
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
>> > vary
> 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
&
ble 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.
> >
>
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 d
10 matches
Mail list logo
