dnf replacing yum and dnf-yum

Radek Holy rholy at redhat.com
Fri Apr 10 14:02:12 UTC 2015



----- Original Message -----
> From: "Jan Zelený" <jzeleny at redhat.com>
> To: "Steve Clark" <sclark at netwolves.com>
> Cc: devel at lists.fedoraproject.org
> 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


More information about the devel mailing list