Save everybody some surprises in Fedora 22!

[Justin Brown]

I've been using DNF for a year or so primarily. The one gripe that I
have is that DNF tends to avoid giving useful information with broken
packages. A required package version isn't available? Yum will print
out tons of information on which package failed, what version is
installed, and what version is available through yum. On the other
hand, DNF just gives up without any useful output. Absolutely no
information that there was a package conflict, much less what the
details are.  With Fedora embracing community repositories through
COPR, the default packaging tool absolutely needs to present this
information to users.

There are also still situations where a user gets a Python stack
trace, which is, bluntly, sloppy programming. Exceptions always need
to be handled and presented in a reasonable format for users. The
failure to catch exceptions instills the belief that the authors don't
understand the failure modes of their application.

I'll make one additional comment about how DNF doesn't go far enough
to actually be useful enough to be next-generation. The slowest step
for users who keep their packages generally up-to-date is the download
and parsing of metadata. The Fedora OS repository metadata is over
36MiB (and completely static after release) that has to be downloaded
and still takes a long time to parse. Why DNF didn't attempt to even
address server-based queries or partial metadata download is beyond
me. I shouldn't need to download full metadata of all packages just to
figure out what needs to be updated, and similarly a package queries
should happen on the remote mirror. There's no reason why every client
needs to download and parse that much metadata.

While DNF works pretty well and is marginally faster, it doesn't
really offer that much benefit. I anticipate that we'll see DNF 2 or
some other new package manager show up that at least alters the
metadata situation if not going radically parallel to support
simultaneous modification of many packages.


On Mon, Jun 9, 2014 at 4:58 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On 06/09/2014 05:49 PM, Jan Zelený wrote:
>>
>> On 9. 6. 2014 at 16:41:59, Ralf Corsepius wrote:
>>>
>>> On 06/09/2014 02:30 PM, Matthew Miller wrote:
>>>>
>>>> On Mon, Jun 09, 2014 at 09:59:15AM +0200, Jan Zelený wrote:
>>>>>>
>>>>>> till October) will give folks plenty of time to hone their dnf skills.
>>>>>> IMO, for many (majority?) it will be a drop-in replacement for yum.
>>>>>
>>>>>
>>>>> Yes, that's the plan. There are some differences but they are all well
>>>>> documented.
>>>>
>>>>
>>>> Is the plan to actually rename dnf to yum at that point?
>>>
>>>
>>> 1. Is there a yum compatibility test suite? It dnf is supposed to be a
>>> drop-in replacement, not having one would seem grossly silly and should
>>> be treated as "full stop show stopper".
>>>
>>> 2. If dnf is supposed to be a drop-in replacement, a more reasonable
>>> approach but to force dnf upon all users by brute force, would be to
>>> apply "alternatives".
>>>
>>>> If it is truly a
>>>> drop-in replacement, that seems like the less disruptive approach for
>>>> users
>>>> (and scripts) everywhere.
>>>
>>>
>>> Agreed. I regret, but so far, dnf I do not see much sense in dnf.
>>
>>
>> Dnf is not supposed to be 100% drop-in replacement (hence the list of
>> incompatibilities in the dnf documentation). I'd rather say that it's
>> supposed
>> to be as compatible as possible, focusing on the most widely used features
>> first.
>
>
> Well, in this case ... you don't want to hear, what I think of this.
>
> What you currently are doing, definitely is against the Fedora users'
> interests, to say the least.
>
> Ralf
>
>
>
> --
> users mailing list
> users at lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org