On Wednesday, 26 November 2008 at 12:56, Nicolas Mailhot wrote: > > > Le Mer 26 novembre 2008 11:54, Dominik 'Rathann' Mierzejewski a écrit : > > > > On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote: > >> 2008/11/25 Till Maas <opensource@xxxxxxxxx>: > >> > On Tue November 25 2008, Nicolas Mailhot wrote: > >> >> The magic of -n will mean confused bug reporters that waste time > >> >> searching for an srpm that does not exist anymore > >> > > >> > Why should people search for this srpm? > > Because all our tools including bugzilla list srpm names, not rpm names. That's something that could be changed. Why can't bugzilla map rpm names to srpm names automagically? Also see below. > >> > And if there > >> are not, > >> > then they will at least learn how to search for an srpm the right > >> way, after > >> > they reported a bug. > > To report a bug they need to know the srpm name That shouldn't be a requirement. In fact, I remember some discussion around here about providing some bug-reporting aid tool that would provide some of the necessary details automagically (srpm name being one of them). > >> I do not believe that not having a separate srpm for this will be a > >> problem. Anyone that needs it will probably figure it out. > > > You can always check which src.rpm a package was built from with rpm > > -qi. > > You can do a lot of things, but my point is > 1. most people won't bother and therefore > 2. magic packages where the rpm -> srpm relation is not obvious are > just introducing drag and problems in the Fedora workflows. That should not be an argument to force packagers to use convoluted rpm names. Building monodoc.rpm from mono.src.rpm is perfectly fine if they come from a single tarball. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list