Re: should all bug reports be filed against /source/ packages?
Guillem Jover writes:
> On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
>> the thread about naming (source) packages reminded me of an other thing:
>> Debian's bug tracking system currently (mostly) tracks bugs against
>> binary packages and (less often) against source packages.
>
>> It gets confused if a source & binary package with the same name, but
>> otherwise unrelated exist; or when the same binary is built from
>> different sources on different architectures;
>
> I think this is a bogus practice that dak or ftp-masters should
> outright reject on NEW processing. The second case might have been
> valid in the past, but I don't think it is anymore since we have
> versioned provides. I consider these to be bogus because I don't
> think we can properly tell the infra which would be which w/o some
> kind of manual intervention.
It's bogus practice to confuse source & binary package namespaces which
too many places in our infrastructure do (including the BTS).
>> or when binary and source versions don't match (version tracking really
>> should use source versions).
>
> debbugs at least has the apparent support for source and binary
> versions at least at filing time, where you can do:
>
> Package: binary
> Version: version-binary
>
> or
>
> Source: source
> Source-Version: version-source
>
> if that does not really do what it's supposed to do, or other parts
> get confused, I'd say this is a bug in debbugs that should ideally
> be fixed.
Trying to implement version tracking for binary versions is so complex
and provides so little benefit (IMHO) that it's not worth trying to do
so...
Please keep in mind that there is no historic version information for
binary versions (unlike d/changelog for source history) and that source
pcakages can build binary packages with arbitrary versions, i.e. you
cannot assume anything about relationship between source and binary
versions.
Debian's infrastructure also only uses source versions to close bugs...
>> In addition there are issues when binary packages get
>> renamed (e.g. when libfoo1 gets dropped in favor of libfoo2).
>
> This is indeed a valid point, and it would be nice to get support to
> handle this in an easier way. Say a debbugs command to mass reassign,
> or some way to designate the new package as a successor of the old
> one, so that the infra could do the reassignment itself, or similar.
Why more complicated solutions?
>> I believe bugs should always be assigned to source packages as source
>> packages are really the unit we use to keep track of packages.
>
> In some contexts that might be true, but for bug tracking and triaging
> just using the source package implies a massive loss of relevant data
> and grouping. :/
You can still use other grouping mechanisms (usertags). Binary package
names and versions should probably also still be included in the bug
report, just as we do for other useful information such as dependencies.
>> So I'm wondering if we should start just filing all bug reports against
>> source packages? Reportbug could probably be easily changed to use
>> `Source: ...` instead of `Package: ...`; more places could follow later.
>
> I actually find it slightly annoying when getting bug reports relevant
> only to a binary package filed against the source package, as that's
> something else I need to fix.
>
> Personally I only ever file against source packages, when the bug is
> relevant to the actual source package, say f.ex. the packaging bits or
> the upstream build system, something in the actual source, say some
> licensing issues, etc.
Which bugs don't fall into this category? Not being relevant to all of
the packaging bits, build system, actual source, and licensing issues
seems to leave very few things open that would not be filed against
source packages according to your list.
Ansgar
Reply to: