DNF as default package manager

[Vít Ondruch]

Dne 21.1.2015 v 12:04 Peter Robinson napsal(a):
>>>> 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?
> Have you done test scratch builds with it for 18K+ packages in Fedora,
> for all the other processes that are run in mock that would use it as
> part of the day to day rel-eng process and published all the stats
> there? I've not seen anything and I watch it all pretty closely. Being
> part of the Fedora rel-eng team I want to be sure that it it's stable
> and able to reproduce all the processes and we don't have massive
> amount of regressions.
>
> The new developments in mock have broken a bunch of functionality due
> to them not being tested (live and disk images that I'm aware of), add
> in a swap in package management without wide testing and we're just
> asking to delay F-22 on a tight schedule.
>
> I look forward to seeing the details of a mock based mass rebuild with
> the new mock and dnf :-)

I might have false expectations, but you as the member of rel-eng team
should probably drive this effort, together with DNF guys. Its kind of
stupid to come here from my position and ask this questions, but
somebody should ask them anyway.


And TBH, yes, there are issues in dependency resolution in DNF. As an
example, I see that DNF pulls in jruby in places where YUM used to pull
in ruby. But

1) It is not show stopper
2) It is easy to fix if you know it happens
3) DNF is not going to change, so it must be fixed in packages anyway.


I'd be glad if somebody of rel-engs can give us the list of packages
which suffers similar issues.


Vít