----- Original Message ----- > From: "Jan Zelený" <jzeleny@xxxxxxxxxx> > To: "Steve Clark" <sclark@xxxxxxxxxxxxx> > Cc: devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, April 10, 2015 3:15:42 PM > Subject: Re: dnf replacing yum and dnf-yum > > On 10. 4. 2015 at 08:56:16, Steve Clark wrote: > > On 04/10/2015 08:40 AM, Jan Zelený wrote: > > > On 10. 4. 2015 at 07:16:30, Steve Clark wrote: > > >> On 04/10/2015 07:04 AM, Jan Zelený wrote: > > >>> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote: > > >>>> Am 10.04.2015 um 09:18 schrieb Jan Zelený: > > >>>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote: > > >>>>>> I very much agree with this. As a user, I expect that 'dnf upgrade' > > >>>>>> will > > >>>>>> give me latest packages and that DNF will tell me the fact that > > >>>>>> newer > > >>>>>> packages are available but not installable. > > >>>>>> > > >>>>>> Maybe it could have a form of plugin, at least for the beginning? > > >>>>> > > >>>>> Again, dnf check-update already does that > > >>>> > > >>>> Again: that argument is pointless because *nobody* is calling it by > > >>>> hand > > >>>> after "dnf upgrade" and so that information is *not* available for the > > >>>> regular dnf/yum user > > >>> > > >>> The vision for dnf is to be more simple and more effective tool for > > >>> admins > > >>> that will not try to solve problems of other components. On the other > > >>> hand we want to enable package maintainers and other advanced users to > > >>> achieve their use cases somehow but dnf will never be a debugging tool. > > >>> Bottom line, we will consider this feature request but considering it > > >>> is > > >>> the only promise I can give you. > > >>> > > >>> Thanks > > >>> Jan > > >> > > >> Mr. Zeleny, > > >> > > >> As an admin and user how does this behavior make it simpler for me? I > > >> now > > >> have to do 2 steps to make sure things worked as expected. How is this > > >> simpler? > > > > > > What we envision is for the admin not to debug the problem himself, it's > > > not his responsibility. Packaging problems should be discovered > > > automatically when an update is created. This is being worked on by > > > Fedora QA IIUIC. Package maintainers are the second line of defense, as > > > they should resolve these problems before updates go stable. But these > > > issues should never get to the end user. > > > > > > Bottom line, if an update is in a repo but it's not installable, it's > > > technically not available to the client as some of the bits are obviously > > > missing. Maybe you could help me understand what value does the > > > information > > > have for you when you can't install the packages anyway. > > > > > > Thanks > > > Jan > > > > Mr. Zeleny, > > > > It is naive, in my opinion, to assume that Fedora is going to supply all > > the > > packages one might need. I quite frequently run into the problem of > > dependencies from other repos clashing with Fedora's, and others and have > > to use the information provided by yum to determine how to clean things up. > > In what is proposed now I will have to do two steps to determine there is a > > problem. > > > Ok, I think I understand your problem a little better now, even though I > still > maintain the opinion that dnf should not be a debugging tool. I have seen a > few proposals here that have the potential to be a nice compromise. > > Also I wonder if dnf check-update is actually useful. From what I've read > here, it seems it's barely used. If dnf is to have its functionality covered > by the upgrade command, perhaps it's possible to remove the check-update > command. FYI, at first sight, the implementation of "dnf check-update" is almost the same as "dnf list upgrades" except that "check-update" returns a special exit code... -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
