On Mon, 2008-10-06 at 12:48 +0200, Patrice Dumas wrote: > 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, ...). ACK. > 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. Right. In particular in cases where packages can easily be modified to better suite into distribution (Think --program-prefix). > 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. ACK. Also consider there may exist applicable standards, which may interfere on such common names and may force/overrule such upstream choices. > In theory, upstream should think about those issues when choosing a > name and avoid misusing these scarce words, but this is not what > happens. Well, we are having a review quality problem. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
