dnf versus yum

[Reindl Harald]

Am 05.01.2014 09:40, schrieb Reindl Harald:
>> They really want to make dnf work this way.
>> This is explained here:
>> http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel
> 
> and that is clearly a regression
> 
> how likely is that somebody want to delete all kernels include the running one?
> "the user can always specify concrete versions on the command line" - yes, at
> the same time the user can "rpm -e --nodeps" if he really knwos what he is doing
> 
> the same for:
>> protected_packages is ignored
>> DNF drops Yum’s protected_packages configuration option. Generally, DNF lets the user
>> do what she specified, even have DNF itself removed. Similar functionality can be
>> implemented by a plugin
> 
> "DNF lets the user do what she specified" is nonsense, the system must not destroy itself
> without *explicitly* specified this action via a *non-default* switch

the following paragraph would only be true if the UsrMove would have
been finished which is not the case, otherwise i would not be forced
to carry a meta-apckage with "Provides:  %{_sbindir}/ldconfig" even
in F20 because all my self-maintained packages have done UsrMove

i had this fun recently by upgrade to F20 with yum because for
dependency solving the metapackage was temporarly removed and
there are still issues if glibc and other packages are updated
at the same time

so for me there are two choices:

* finish UsrMove and stop refer to /bin and /sbin anywhere in the distribution
* let DNF not assume a finished UsrMove
______________________________

dnf provides /bin/<file> does not find any packages on Fedora

After UsrMove there’s no directory /bin on Fedora systems and no files get installed there, /bin is only a symlink
created by the filesystem package to point to /usr/bin. Resolving the symlinks to their real path would only give
the user false sense that this works while in fact provides requests using globs such as

-------------- 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/20140105/6b359428/attachment-0001.sig>