Re: fixing yum

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]