Description of problem: When dealing with Red Hat Enterprise Linux and sub-repos there is a tendency of people not to know where their RPM came from. We are seeing this with combinations of EPEL, RPMforge, adn RHEL. In meeting about this it was asked to file an RFE for adding a bug reporting URL so that Reply | Jesse Keating Or perhaps a bug reporting URL field in each rpm. Accessable via rpm -qi or a scriplet. This would allow for faster entry of bugs to the appropriate sources. This would also help for internal helpdesks to get stuff directed to them faster. Jul 18 (2 days ago) Jesse Keating: On Jul 18, 2009, at 15:07, inode0 <inode0> wrote: There are several common cases that come up. One simple one is a user has a problem with a particular package and its source needs to be determined so they can report the bug or whatever. When rpm -q package identifies the source everyone's life is just about as easy as it could possibly be. If you find a simpler solution I'd love to hear about it. Expecting someone providing help to ask that user to do what Thorsten provided for 2 or 3 repos is not a simpler solution and is really laughable. Yes, there are other ways we can extract the information from the user, they take more time and effort on everyone's part. As far as a script helping goes it would only help if it were provided by Red Hat has part of RHEL. Otherwise it would not be available universally as not everyone uses any particular 3rd party repo. And if they (Red Hat) would agree to such a thing, unlikely I think, it might as well be part of rpm, like rpm -q --where-the-heck-did-this-come-from package. Or perhaps a bug reporting URL field in each rpm. Accessable via rpm -qi or a targetted query. -- Jes
Upstream rpm now knows about BUGURL tag which can be specified in either the spec or through macro configuration.
I'm not sure whether the explicit BugURL: tag in spec is the best option for this purpose. If we want to have a bug URL present in each rpm it is IMO better to define the bug URL in /usr/lib/rpm/macros or elsewhere distribution-wide. With this concept it is needed to bother each packager to add BugURL: field in spec. If a macro with bug URL is defined and rpmbuild writes its contents to RPMTAG_BUGURL in rpm header, then just a rebuild is needed without packager's intervention or Fedora policy packaging changes.
The template for %bugurl to set it directly in /usr/lib/rpm/macros is now added in upstream as well.
Except you dont touch /usr/lib/rpm/macros, you set it on buildsys macro configuration. Having it mentioned in /usr/lib/rpm/macros only serves as documentation at a somewhat obscure place :) but of course doesn't hurt anything to have it there. Distros and 3rd party repositories obviously want to use the macro option to avoid having it on each and every spec, but spec can be used to override the default (eg if for some package bugs at upstream tracker are preferred) and upstream provided packages.
Yup, the spec BugURL: tag overrides the macro regardless the place it comes from so it sounds like it works :)
The rpm bits have been added in rawhide, now we just need something to actually set the macro. redhat-rpm-config I suppose...
This comes bit late, but anyway: Would it be a good idea to also specify somehow what kind of bug url is that? Like web page for humans or xmlrpc connection? Or have own url for that? And what bug tracking system it is? (that might be easy to try thou.) It's possible to try to guess it but I guess there is no common convention / relation between web pages and xmlrpc url. I thought that if someone ever makes some more generic, cross distro bug reporting tools for client end, that might be useful.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
So, somewhere down the line this actually happened: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XDEF3WPXV75MEI4W6G66V3UMAF6DIVDE/ Since this went into builder configuration I don't know what the right component would be, so closing it right here.