dnf versus yum

Reindl Harald h.reindl at thelounge.net
Thu Jan 2 20:30:35 UTC 2014


Am 02.01.2014 21:21, schrieb Rahul Sundaram:
> On Thu, Jan 2, 2014 at 3:14 PM, Reindl Haraldwrote:
>  the bahvior is obviously not (or *not yet*) identical and the viewpoint
>  what are not often used bordercases may vary and depend on the environment
>  as i pointed out "yum -y remove kernel" is a regular task here after machines
>  are running long enough with the last recent one as cleanup
> 
> I agree with that and the kernel removal behavior isn't the only difference.  I mean, how often would one run dnf
> remove glibc on purpose and the significant amount of accidental runs of yum that caused serious problems resulted
> in yum developers adding some protection against removing key packages.  dnf changing this expected behavior is
> problem and clearly this is a design decision which I think needs to revisited.
> 
> http://akozumpl.github.io/dnf/cli_vs_yum.html#protected-packages-is-ignored

thank you!

that and the plugins / utilities below should be taken care of and than IMHO
DNF will be a *painless* drop-in replacement, working that way and after it
has that state it could be really replace yum including respect the existing
configuration of /etc/yum.conf and /etc/yum.repos.d/ with excludes, includes

yum-utils
yum-plugin-security
yum-plugin-tsflags
yum-plugin-protectbase
yum-presto

one example of a production machine which pulls it's updates from cache-repos
only so no deltarpm and no manuals on all servers needed, that's why the
cache-repo is filled with the script below for several resons

* only one machine producing traffic on the mirrors
* 100% identical packages while otherwise one may hit a newer mirror
* the buildserver has for most packages sample-configs and autotests
* so while reduce WAN-traffic dramatically there are only tested packages inside the whole network

that's some of the "small" things one needs to take care in production and
only the renaming of /var/cache/yum to /var/cache/dnf may produce side-effects
even with otherwise identical behavior
_______________________________________________

[main]
cachedir=/var/cache/yum
installonly_limit=2
metadata_expire=60m
clean_requirements_on_remove=1
tsflags=nodocs
deltarpm=0

[root at buildserver:~]$ cat /buildserver/repo-cache.sh
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf "%{version}\n" fedora-release`
for g in `ls -1b /var/cache/yum`
do
 if [ -d /var/cache/yum/$g/packages ]
 then
  echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/"
  sudo mv --verbose /var/cache/yum/$g/packages/*.rpm /repo/cache/fc$releasever/ 2> /dev/null
 fi
done
/buildserver/repo-create.sh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140102/af470f57/attachment.sig>


More information about the devel mailing list