DNF as default package manager

[Peter Robinson]

On Wed, Jan 21, 2015 at 11:23 AM, Vít Ondruch <vondruch at redhat.com> wrote:
> 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

Isn't it? In the build system I suspect you'd either get:
1) a failed build
2) a package without ruby features
3) something unexpected

It might not be a show stopper for a standard package install but it
is for reproducible builds

> 2) It is easy to fix if you know it happens

When rel-eng is doing a mass rebuild of 18K+ packages how are we
suppose to know it happens? How do we know there's not thousands of
other weird substitutions happening without checking build logs? Are
we expected to cross referencing previous logs to see if there's
changes or if it's the same?

> 3) DNF is not going to change, so it must be fixed in packages anyway.

So there's known issues your not going to fix and, from the comment
below, you don't know if there's other similar issues or ones that
might be worse?

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

Are we expected to cross referencing previous logs to see if there's
changes or if it's the same and provide you that information? We
already have too much to do so it's easier to stick with yum where we
know what the outcome is. Sorry, not going to do your work for you!

Peter