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
_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel
