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].
See [2] for the release notes.
Ales
[1] http://bit.ly/16UCuom [2] http://akozumpl.github.io/dnf/release_notes.html#id9 [3] https://bugzilla.redhat.com/show_bug.cgi?id=984483
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?
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.)
I'd strongly urge you to consider the side-effects of this change.
On Wed, Jul 31, 2013 at 3:06 PM, James Antill james@fedoraproject.orgwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 01/08/13 02:36, Ed Marshall wrote:
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.
regarding priorities/costs, I filed an RFE bug some time ago: https://bugzilla.redhat.com/show_bug.cgi?id=967798
On 08/01/2013 02:36 AM, Ed Marshall wrote:
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.
In cases like this it would be a good idea for the high priority repo to set skip_if_unavailable = False.
Ales
On 1 August 2013 08:41, Ales Kozumplik akozumpl@redhat.com wrote:
In cases like this it would be a good idea for the high priority repo to set skip_if_unavailable = False.
100% agreed.
Richard.
On Thu, Aug 1, 2013 at 12:41 AM, Ales Kozumplik akozumpl@redhat.com wrote:
On 08/01/2013 02:36 AM, Ed Marshall wrote:
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.
In cases like this it would be a good idea for the high priority repo to set skip_if_unavailable = False.
I don't disagree with you, and I'll be making the necessary changes to make sure I don't get bitten by a change of behavior here, regardless of what happens.
I'm just bringing it up because I'm likely not the only one using yum priorities, and this is a subtle side-effect of that; one that some folks might not be aware of (and while I'm aware of it, I didn't consider the possibility that the defaults might change out from under me ;)).
In the dnf case, it likely doesn't matter; I don't think dnf has grown support yet for repo cost/priority yet, has it? I only commented because I saw the BZ suggesting a similar change for yum, and wanted to warn that changing a default like this in mid-release might catch a few people by surprise.
(I was a little concerned to see that change show up mid-release for dnf, to be honest, but at least dnf's adoption is limited to the curious right now.)
On 08/02/2013 02:28 AM, Ed Marshall wrote:
In the dnf case, it likely doesn't matter; I don't think dnf has grown support yet for repo cost/priority yet, has it?
No, not yet, that's one of the things waiting to happen still: https://bugzilla.redhat.com/show_bug.cgi?id=967798
(I was a little concerned to see that change show up mid-release for dnf, to be honest, but at least dnf's adoption is limited to the curious right now.)
It happened Fedora mid-release, yes, but not DNF mid-release. Of course, this practice will have to stop once DNF is no longer an experimental thing.
Ales
On 08/01/2013 12:06 AM, James Antill wrote:
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?
Hi, it's not silent there's a warning about the repo being skipped.
Ales
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?
Hello James,
I responded to your comments in the bugzila: https://bugzilla.redhat.com/show_bug.cgi?id=867389
Regarding Dropbox, it is broken for at least a month after each Fedora release, regularly. For F19 they added their repository just very recently. You can't force them to fix it. And even if you do, there will be always other repos which will have the same problem.
In my bug report I speak for users who don't know that --enablerepo/--disablerepo exists.
On 08/05/2013 03:58 PM, Kamil Paral wrote:
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?
Hello James,
I responded to your comments in the bugzila: https://bugzilla.redhat.com/show_bug.cgi?id=867389
Regarding Dropbox, it is broken for at least a month after each Fedora release, regularly. For F19 they added their repository just very recently. You can't force them to fix it. And even if you do, there will be always other repos which will have the same problem.
In my bug report I speak for users who don't know that --enablerepo/--disablerepo exists.
Perhaps the error message for unavailable repo could be used to educate users about --enablerepo/--disablerepo and the skip_if_unavailable setting.
- Panu -
I responded to your comments in the bugzila: https://bugzilla.redhat.com/show_bug.cgi?id=867389
Regarding Dropbox, it is broken for at least a month after each Fedora release, regularly. For F19 they added their repository just very recently. You can't force them to fix it. And even if you do, there will be always other repos which will have the same problem.
In my bug report I speak for users who don't know that --enablerepo/--disablerepo exists.
Perhaps the error message for unavailable repo could be used to educate users about --enablerepo/--disablerepo and the skip_if_unavailable setting.
- Panu -
I completely agree, I provided the same idea into the bugzilla. Maybe the educated users would then bother dropbox and other parties to mark their repositories non-essential and the whole situation could improve a bit.
devel@lists.stg.fedoraproject.org
-
Ales Kozumplik -
Ed Marshall -
James Antill -
Kamil Paral -
Matthias Runge -
Panu Matilainen -
Richard Hughes