[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