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

Ales Kozumplik akozumpl at redhat.com
Wed Jul 25 07:02:22 UTC 2012


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).

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. 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. (Or have it marked during 
the install process as "userinstalled", because for instance "this is a 
nice desktop distro and nobody wants to see the systemd startup text 
feed" etc.)

One could argue that having it off by default is OK since people can 
read the documentation and turn it on. But, we've seen the "wow, Yum can 
do that!?" surprise in the thread. Some average user don't read the 
documentation, the wikis, the release notes. Only complains "this is 
better in Debian". And then it was wasted energy on our side.

> ...it's also likely to be a big problem with any GUI, unless the GUI
> knows about the option and how to turn it off (or, better, show the user
> what could happen, and why).

I haven't thought of this aspect much yet. Hopefully the parties writing 
GUIs will read more documentation than the end users and configure DNF 
to perform as they expect.

>
>   I would also argue, again, that just because DNF will have to change
> _some_ behaviour doesn't mean you should randomly change other
> behaviour. Even little changes will add up, and make it harder to
> transition or see what is a bug and what is a feature and general just
> cause problems/fear/uncertainty/doubt/etc. (Eg. see the py3k disaster).

You have a valid point. I try to keep the things that change to a 
minimum amount and decide case by case. This particular one seems 
beneficial, there's still no bugreport proving it is broken in an 
inherent way. Furthermore it is implemented by adding

clean_requirements_on_remove=true

in the config file and not by inverting some internal constant. So I'd 
say it is exposed enough and shouldn't surprise anybody.

Ales


More information about the Yum-devel mailing list