DNF as default package manager

[Peter Robinson]

On Wed, Jan 21, 2015 at 12:13 PM, Jan Zelený <jzeleny at redhat.com> wrote:
> On 21. 1. 2015 at 11:13:28, Peter Robinson wrote:
>> >>>>> But I'm really interested in state of DNF as default too. Should I
>> >>>>> switch mock to use DNF as default? For me there is still lot of
>> >>>>> unfinished tasks. E.g. documenting what --installroot should actually
>> >>>>> do [BZ 1163028]>>>>
>> >>>> I don't think it's ready, it might be useful to have an option to
>> >>>> switch it over for local use to enable easier wider testing but I
>> >>>> certainly don't think it's ready to be default for mock yet.
>> >>>>
>> >>>> Peter
>> >>>
>> >>> I am using mock for Fedora development with DNF enabled by default and
>> >>> it works just fine. May be you want to share what is troubling you?
>> >>
>> >> There is a difference between « it works just fine for me » and « it
>> >> works to build the distro »
>> >>
>> >> The latter needs much more testing and guarantees than the former,
>> >> although the former is certainly encouraging.
>> >
>> > If somebody says "I certainly don't think it's ready to be default for
>> > mock yet.", I expect him to have strong evidence that something is
>> > wrong, not that something needs more testing.
>>
>> If somebody says that it's ready to go I would expect them to have
>> used mock to rebuild the entire distribution and prove that it works,
>> preferably twice actually once as an initial run from the original yum
>> builds, then again with dnf for a second run and prove, with
>> statistics to show that installs of said bits end up with the same
>> reproducible results for things like Workstation/Server/Minimal etc
>> installs.
>>
>> The onus in Fedora has _ALWAYS_ been to prove that the new feature is
>> complete and ready to replace the existing working solution, not for
>> everyone else to prove that it's not.
>
> I'm not so sure about that. Off the top of my head, I can think of rpm-4.12,
> UsrMove and systemd - those were neither proven flawless, nor they have been
> without issues when deployed. I bet there was at least one major change in
> each Fedora that was not flawless when accepted.

For both UsrMove and systemd there was analysis of packages with
issues, migration paths over a number of releases, bugs reported
against packages, quite often with patches (eg new arch bring ups) so
the maintainers knew there was a problem. I've seen none of that with
dnf to ensure as much as possible is fixed before hand, all I've seen
is an attitude of "this isn't our problem"

>> Given the number of issues I see reported with dnf regarding dependencies
>
> Obviously different depsolver = different results. Some of them for the better,
> some of them for the worse. But those that are proven problematic are baing
> taken care of continuously.

Yes, no issues there but I've not seen changes in packaging policies
through the packaging working group if there needs to be changes
there, there was mention of issues with ruby vs jruby. There's no
doubt others.

>> current kernels being removed
>
> This was fixed almost a year ago

There have been others cone up more recently, don't remember if it was
glibc or rpm or similar.

>> and other such issues
>
> Name them please. Or better yet, report them.

I don't use dnf anymore currenty as it caused too many issues so I
went back to yum, but I see regular discussions of issues on devel@
and testing@

Peter