Bug#78012: Origin and Bugs headers proposal
> > 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.
Reply to: