On Wed, 27 Aug 2014 14:02:12 -0600, Kevin Fenzi wrote: > > The primary problem with Rawhide and repository mirror propagation > > times is: you can get the "wrong" builds, e.g. a set of updates that > > breaks your system, while developers (or packagers) have submitted a > > new build (or even a hot-fix) already that is supposed to fix a > > problem after the next compose. > > So you get it in the next compose? Sometimes. Provided that the issue did not corrupt anything, does not lead to boot problems and does not prevent from updating (aka Yum breakage). For instance, some scriptlet mistakes mess with symlinks, with file contents, with config files, and with alternatives -- they cause damage. The fix in a next compose will no longer cause damage, but doesn't _repair_ the damage that has been caused earlier. > If a maintainer noticed the problem before the build went out in a > compose, you would only see the fixed one. If they saw it only after > the compose, you should see the fixed one after that? It's not that easy. There are more factors that are relevant, such as errors during boot, crashes during login, broken dependencies (will --skip-broken lead to trouble because of unversioned deps?), mirror propagation times (it takes multiple days for updates to become available at a nearby mirror, whereas some people install packages from koji/copr as well as from private repos that are ahead of Rawhide). > I usually do update daily, but at times I do not. I didn't update for a > week or so around flock, and had no particular problems. > I have another rawhide machine at home that I sometimes don't update > for days/weeks at a time anymore, and it's only had the occasional dep > issue that was pretty easy to fix up/work around. Well, experience differs. My experience is that over time, Rawhide breaks into pieces either slowly or all of a sudden. Up to the point that a reinstall would result in something that works better, because reporting strange symptoms seldomly is fruitful. > Anyhow, if you have suggestions for improvement, I'm all ears. There are still packagers, who don't - build for Rawhide before building for F20/F21, (i.e. don't violate the upgrade paths) - smoke-test your builds on a local installation before releasing them (i.e. notice whether a program segfaults immediately!) and for library upgrades - examine the effort it takes to perform library ABI/API upgrades, (i.e. talk to all dependency owners before breaking dependencies). -- Fedora release 21 (Twenty One) - Linux 3.16.1-300.fc21.x86_64 loadavg: 0.13 0.17 0.19 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
