On Mon, Oct 06, 2008 at 11:39:52AM +0200, Tim Niemueller wrote: > > That has been discussed during the review and the reasoning was that the > project chose that name and renaming it would only cause unexpected > hassles for people who install this software. Upstream chose that name, > so if we want that package we should stick to it, if only to allow users > to reproduce commands given in documentation, wikis, blogs etc. > Additionally your very repoquery shows that there are in fact no > conflicts, so why bother? > > I also don't see a problem why binary in the package for which this > thread was initiated should be renamed. There is no trash command, it > provides functionality which clearly fits the name, so why the heck > should it be renamed? Just because someone might as well add such a > command later? It's like not using your roller skates to keep them in a > nice new condition, until you have grown out of them... The issue is that many upstream don't care about using names that are not prone to future conflicts, and use generic names. In my opinion, generic names should be reserved to standardized programs (like sendmail, ls, ...). Upstream don't care and selfishly choose the name that suits them most, but at the distro level, and for the long-term, I think that we should try to regulate a bit those namings such that projects don't take these precious names carelessly. To put it otherwise, the generic names (like trash, player, record, convert, ...) and the short names (like ls, qpd, fjk, tgn...) are scarce and a first come first serve is certainly a bad way of choosing them. In theory, upstream should think about those issues when choosing a name and avoid misusing these scarce words, but this is not what happens. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
