F22 System Wide Change: Replace Yum With DNF

[Reindl Harald]

Am 14.06.2014 03:10, schrieb Michael Scherer:
> Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit :
>> Am 14.06.2014 02:59, schrieb Michael Scherer:
>>> Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
>>>> On 06/13/2014 09:03 AM, drago01 wrote:
>>>>
>>>>> On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>>>> Am 13.06.2014 14:53, schrieb Jan Zelený:
>>>>>>> That being said, the reason for not renaming dnf to yum is that renaming this
>>>>>>> project to yum will do nothing else than to confuse its users, as they will
>>>>>>> think this is still yum and they should expect from dnf it what they expected
>>>>>>> from yum. They should not. And dnf is not yum, I'm really sorry if you think
>>>>>>> it is.
>>>>>> the user expects that anyways if you replace something he
>>>>>> did not asked for replace it and what just worked for him
>>>>> Well there are different levels of "works" i.e just because something works that
>>>>> something does not have to be the best possible implementation of
>>>>> "something" ...
>>>>>
>>>>> Horses worked too but at some point we decided that cars work better
>>>>> and moved on.
>>>> Yes but who is this better for? A few developers or the mass of people
>>>> and documentation that
>>>> are used to using "yum".
>>>>
>>>> With cars it was obviously better for me - dnf not so obvious.
>>>
>>> So far in this thread, I see no one stepping to maintain yum in the long
>>> term, just people asking to others to do it.
>>>
>>> But having someone volunteering to maintain it would be the solution.
>>> People who want to keep yum forever, just maintain it
>>
>> what are you talking about?
>> *nobody* asked that *nobody*
> 
> Nobody did ask that explicitly. But if people want to keep all howto
> running, either we keep yum as is, or we define what exactly should be
> preserved and what can be removed

why do functions and options need to be removed due a
code-rewrite/re-factoring? to clean up the code base?

if someone takes the word "improve" in his mouth i
don't see a place for "remove" in the same context

the "dirty codebase grown" that way because previously unplanned
features where included and it it pretty silly to cleanup things
by step back from where it came which leads a few years later to
the same problems: options left and right are included in a
codebase originally not designed for it

that's fine for developers because that way you can start every
few years from scratch with remove, re-write and cleanup but it
hardly gains anything for the users

a smart re-write is using the benefit knowing what all sort of options,
functions and configurations where  added all the time before and
organize the codebase to implement it in a better, more generic way
with sane (API) interfaces

throwing all away, start with a minimum and be proud
it's faster and cleaner is only a short term solution


-------------- 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/20140614/7cb80e32/attachment.sig>