> > What is the status of this proposal? Are we still undecided on its > > merits or do we just lack patches to the policy and packaging manuals > > to codify it? > > I'm still in favour of my proposal. > > > If we don't have consensus on this approach, maybe Nicolás' > > implementation of the concept within the package itself (rather than > > in the package control file) is appropriate; see > > /usr/doc/bug/README.developers for a description. > > Having to install a package to get the information is a downside imho, > I frequently file bugreports for packages having a wrong description > without ever installing them for example. > > > FWIW both methods are implemented by reportbug, so neither is that > > hard to do... I guess it's a tradeoff between Packages bloat and > > littering small files in a directory. > > The bloat of putting it in the package metadata is *much* less then > having lots of small files in a directory actually. > > The system that bug uses also has the major downside that it is > not easily overriden, which is trivial to do using the dpkg approach > by just modifying /etc/dpkg/origins/##### ., and it doesn't support > multiple bugreporting schemes (which vendors have been asking me > for).
The system in `bug' is mainly targeted too to custom made packages, of multiple sources, not just the few well known huge makers of packages like Helix (Ximian! =) ) or Corel. These packages will just want an URL/e-mail address, and not a reference to a central config file. If a new system addresses that (and seems to do that), I'm happy with it, and I acknowledge that you've raised valid points, this metadata belongs to a dpkg-header. Anyway, a bug reporting tool may use more data, to produce a more complete bug report. Origin information is just one of the things `bug' supports.
