Jeff Spaleta wrote:
On Thu, Dec 11, 2008 at 12:12 PM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
That wasn't a question. I'll figure out how to test for brokenness after
you tell me how to reproduce exact tested, non-broken states. Or maybe I'll
watch the mail list for subjects like 'sucking' or "dbus disaster" before
doing any updates.
You are the one that introduced the "known broken" terminology and
have used in for like 3.2 million posts in this thread. Its your
concept. Not mine.
For my example of the late FC6 update, the machine didn't boot. I'd say
that's clearly a 'known broken' state at that point. But not much
more than that is clear. Why does that have to happen to more than one
machine? Why does everyone it does happen to have to diagnose it
further than not wanting that package set on any other machine?
2) Once you know its broken how prevent it from going on to a client
system
.... yum's configuration options work just fine for that.
No, I have to know a lot more than "it's broken" to do anything with a yum
configurations. What I'd rather do is find an "it works", tested set and
duplicate that and only that.
If I tell you that "it works" is that enough for you?
If you have identical hardware, an identical set of other packages, and
a similar workload, yes.
Are you willing
to trust me on that? Are you willing to trust any individual
maintainer on that?
It's not a matter of trust for at least couple of reasons. One is that
your hardware and installed package set is probably nothing like mine.
Another is that a maintainer might not be running the same version he
pushed to everyone else, either by design or mistake.
I'll just write an auto-fire script to send you
email every time I install an update telling you it works. How do you
define what qualifies as working well enough for you before YOU
install it?
That depends entirely on which machine(s) you are talking about. It
doesn't relate so much to me personally.
What specifically do YOU need to see happen for you to
feel an update is vetted enough for you to install?
Again, it isn't personal - it has to do with the need to keep certain
machines running. And what needs to happen is to know that somewhere,
someone has installed the same package set on the same kind of hardware
and has it still working. Either a dedicated similar test machine would
work, or waiting until some large number of others had run the new
package set with no problems.
And once you tell
us what those things are... are YOU going to help implement them?
I'd be relatively happy to keep a test machine up to date and make sure
it runs and that the programs I care about still work. But, it doesn't
make any sense to do that, knowing that no one else will be able to take
advantage of that and that there is no way to duplicate the tested set
of packages elsewhere. I'd have no privacy concerns about the test
machines - if there were a way to export it's package set, hardware
list, and the fact that it is still working to something that could
accumulate these statistics, that would be fine.
3) If you found out its broken after you installed it on a client
system how do you revert to a previous update?
... you keep a local cache of previously installed updates. yum lets
you keep a local cache..per client. The caching is off by default but
it can be turned on.
Is that really the plan you expect users to follow? Has anyone even tried
that to see if it works in the general case?
I've used it.
That hardly sounds like a recommendation.
On my systems running Fedora which I maintain to be used
and updated primarily by other people (like my wife's desktop).. I do
in fact keep a local cache of previously installed updates which I
purge based on my local administration policy judgement. When there
is an update that breaks functionality for her I am able to manually
install the cached older version and then set an exclude. I don't have
to use it often.
That sounds like at least an admission that the stock tools and
mechanisms aren't good enough.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
