On Tue, 22 Mar 2005 11:07:43 -0500, Claude Jones <claude_jones@xxxxxxxxxxxxxx> wrote: > You suggest that I do targetted > updates, but, how does one figure out the targets? By taking time to learn at least the function description of the package to be updated and reading the changelogs summaries associated with the updates to determine if the update is attempting to fix a noteworthy problem that you are actually seeing. 'If it aint broke....' The development tree daily reports are now coming to the test-list and can be a valuable tool to use to review the changelogs, especially when the changelog references a bugticket number. Reading up about reported bugs that updates try to fix can be a useful thing. You can learn a lot about how things work simply by attempting to confirm bugs that you didn't know existed. How much care you take when testing the test releases has a lot to do with your your personal goals for getting involved, and with your experience level. Very experienced people know enough about subsystems to recover from severe problems without resorting to a fresh install of the operating system, but novice users might not be as capable, so they should take more care. If you just want to give the test releases a spin until something serious breaks, then you don't need to be very careful. But if you want to be an effective tester and assist the developers in get things fixed, being careful and delibrate(even to the point of taking notes in a logbook) can be make it much easier to track down problems. Its very hard to actually diagnose problems if you end up reinstalling to use the system, you are likely wipe out evidence/cause of the problem in the process. > Since I don't fully understand what the effect of > doing that was, I've turned it back on. man yum.conf Does the manpage for yum.conf not give a clear enough explanation of what gpgcheck does? Because package signing in the development tree is a human activated process requiring someone with authority to use the gpg key, the daily updates do not get signed every day. Packages tend to get signed as part of the development freeze process when new test releases or full releases are spun up. As a result if gpgcheck is enabled, yum will notify you if a package you are attempting to update from the developmentr is unsigned and will abort. It is typically desirable to be able to enforce gpg signature checking as a way to verify the package is from the vendor you think its from, so disabling gpgcheck for anything other than the development tree on a non-testing rig is probably very unwise. For the development tree, disabling gpgchecking is almost a requirement if you want to participate in the daily update process. -jef