[Yum-devel] New DNF build: dnf-0.2.7-5.git632e1eb.fc18

James Antill james at fedoraproject.org
Wed Jul 25 17:39:37 UTC 2012


On Wed, 2012-07-25 at 09:02 +0200, Ales Kozumplik wrote:
> Hello,
> 
> On 07/24/2012 06:39 PM, James Antill wrote:
> > On Tue, 2012-07-24 at 16:26 +0200, Ales Kozumplik wrote:
> >> Hello,
> >>
> >> There's a new DNF rawhide build available now:
> >> http://koji.fedoraproject.org/koji/packageinfo?packageID=14310
> >>
> >> Significant changes:
> >> - Clean dependencies during 'dnf erase'.
> >>     DNF will now by default remove packages marked as 'dep' in YumDB
> >> (that is, the yumdb maintained by dnf in /var/lib/dnf). Won't look at
> >> packages in the Yum YumDB and assumes 'userinstalled' if a package is
> >> not found.
> >   I'd thought about turning clean_requirements_on_remove on in yum, and
> > mentioned it on the DNF thread in fedora-devel. But then I was reminded
> > of the unfixable problem with it:
> >
> > http://lists.fedoraproject.org/pipermail/devel/2012-June/169371.html
> > http://lists.fedoraproject.org/pipermail/devel/2012-July/169567.html
> 
> By unfixable problem you mean all the packages we don't know the reason 
> for, yes? In those cases it is safe to assume they were user installed 
> (and never implicitly remove them).

 No, the unfixable problem is that things that the user wants were
installed via. a dep. of something else they also wanted ... and they
will be very unhappy if something decides to remove things that they
want.
 They may also not be aware that they want them, because the package
name doesn't convey the feature it is supplying to them (like "graphical
boot").

> My take is: a feature either does work or it doesn't and should be 
> fixed. There is no point keeping around something optional disabled by 
> default if it doesn't work.

 There is a difference between "works well enough for the people who
want it" and "works well enough that we should force it on everyone".

>  Having it enabled by default speeds up the 
> process of us finding out whether a) the feature works b) it is broken 
> in a fixable way c) it is inherently broken. If it's c) then let's know 
> sooner than later.
> 
> In the second thread Scott Schmit writes "the latest upgrade of dracut 
> no longer requires plymouth.  Since nothing else does, yum was offering 
> to uninstall it for me". Exactly! It is not needed, only slows down the 
> system startup, takes space etc. Remove it.

 Pro tip: When someone says "FOO did XYZ which is surprising and not
what I wanted" then responding with "Exactly!" is not going to help.

 Sometimes you can't fix it, but at the very least you don't want to
give the impression you are happy it's broken (for them).



More information about the Yum-devel mailing list