Re: [Yum-devel] dnf-0..3.10
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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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 -- Matthias Runge mru...@matthias-runge.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
On 1 August 2013 08:41, Ales Kozumplik akozu...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
On Thu, Aug 1, 2013 at 12:41 AM, Ales Kozumplik akozu...@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.) -- Ed Marshall e...@logic.net Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Yum-devel] dnf-0..3.10
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
Re: [Yum-devel] dnf-0..3.10
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 ja...@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 -- Ed Marshall e...@logic.net Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
