Bug#885432: bugs-field-does-not-refer-to-debian-infrastructure for non-Debian packages

[Niels Thykier <niels@thykier.net>]

Russ Allbery:
> Niels Thykier <niels@thykier.net> writes:
> 
>> We have the lintian profile system that enables you to process packages
>> in a different context than "debian" (e.g. "ubuntu" or your own personal
>> context).  The profiles can enable / disable tags (or even change
>> severity of the tags).
> 
>> However, we cannot guess which profile you want based on the package.
>> Partly, because we select the profile first and then process the
>> package.  Partly, because (as I recall) we do not have a reliable
>> indicator of which "derivative" the package is targeting.  In the best
>> case, we only have the "distribution", but e.g. "jessie" is used both by
>> Debian but also third-parties (a notably Devuan, but ISVs may also have
>> their own repositories that mirror the Debian release that they match).
> 
> Yeah, profiles would definitely work.  I wonder if it would make sense to
> have a file in debian/source that indicates the profile in some way?
> 

Beyond a massive rewrite of how we handle profiles (e.g. load checks,
disable tags, etc.), I do have a concern with placing this in the
package as static maintained metadata:

 * What happens when I add this metadata to e.g. lintian or debhelper
   and set its value to "debian".  Then Ubuntu imports it as-is but
   lintian would no longer choose the ubuntu profile by default (instead
   it would go for the debian profile).
   - This case can also be applied to Ubuntu and their derivatives (i.e.
     further "up" in the chain).

I think I lead towards having a dynamic computed field.  E.g. one the
dpkg inserts during package build (source or/and binary) based on the
current "vendor".  However, that would imply that you need to build your
packages as a different "vendor" than Debian (which you probably do not).

Thanks,
~Niels