Making updates-testing more useful
Les Mikesell
lesmikesell at gmail.com
Thu Dec 11 06:23:44 UTC 2008
Kevin Kofler wrote:
> Les Mikesell wrote:
>> Could there be a way to throw everything in the same repo and give the
>> user/installer a choice of how 'well-tested' something should be before
>> installing it? Preferably with a sliding scale instead of just 2
>> choices. Normally on new installs and machines used explicitly for
>> testing I'd expect people to want the latest changes but become more
>> conservative on machines that are working well and used for important
>> work. The 'well-tested' concept might have factors for age, feedback,
>> emergency overrides, etc.
>
> This is horribly overengineered and just can't work (for the reasons Jesse
> Keating already pointed out, so I won't repeat them).
I still don't follow the reason it can't work - unless you remove or
rename packages within the window covered, it should be possible to
pretend newer packages don't exist and get the exactly same package set
that an earlier updater taking everything would have.
> I think the added complexity would also confuse end users, but we don't even
> have to get that far with the discussion because it is impossible to
> implement anyway.
How about brute force with only 2 choices then? For every visible state
of the repository that syncs to the mirrors, make a snapshot copy that
normally ages a month and then appears as a 'safer' repository. In the
abnormal case you could have a procedure to 'fix' things that turned out
to be mistakes, or just skip letting certain instances appear at all. I
think there should be some simpler way to get this effect by
manipulating lists of package names, or using heuristics to ignore some
from a repository contain the full set, but brute force could certainly
work.
--
Les Mikesell
lesmikesell at gmail.com
More information about the fedora-devel-list
mailing list