Also, consider cases where repository priorities are in use; a lower-priority repo that's unreachable may cause unexpected/damaging results for the administrator in cases where there's a package version mismatch.
(This is actually a real case for me: in an environment I work in, a lower-priority repository contains packages which supersede their counterparts in higher-priority repositories, occasionally at lower version numbers. A transient error here could potentially cause the installation of higher-version RPMs from the higher-priority repository; once the error was corrected, a downgrade would have to be manually kicked off.)On Wed, Jul 31, 2013 at 3:06 PM, James Antill <james@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 2013-07-22 at 15:26 +0200, Ales Kozumplik wrote:
> Hello,
>
> I've pushed new DNF version to F19 [1] and Rawhide today. There's only
> little changes but the default value for repos' skip_if_unavailable has
> changed and is enabled now. This is because recently an ailing Dropbox
> repo has made many fine DNF processes end too soon for no good reason [3].
Again I would caution you against just blindly changing defaults to be
incompatible with yum ... even if the yum defaults are bad, every
incompatibility incurs a cost for all users (and it will exist as long
as yum and dnf are being used ... so like 10 years from now). At worst
speak with Zdenek about changing yum's defaults in future Fedora
versions, although even that's still going to be a problem for most
users.
In this case there's a reason skip_if_unavailable defaults to off, with
it on by default most of the package managers output is vastly more
suspect due to having no assurance about which repos. were actually used
to do the operation. And this is 100 worse for any code that does things
like "repo. X can't have packages that exist in repo. Y"
Also a lot of errors become "silent" errors (so things are slow and
don't work well instead of explicitly saying: foo repo. is broken).
Indeed are the dropbox repos. likely to be broken, or would someone fix
them if they knew? Should users have them disabled by default and only
use --enablerepo occasionally? Should they not be implemented as a
direct repo. at all?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Ed Marshall <esm@xxxxxxxxx>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
