Martin Michlmayr has recently reassigned bug #370337 from
"openldap2.3,openldap" to "openldap" because openldap2.3 no longer exists as
a package in the archive, so all mail sent to bugs assigned to this package
is forwarded on to the "no such package" address.  This is an unfortunate
tension between the desire for historically accurate bug information, and the
need to manually redirect bugs reported against non-existent packages to the
right place.

Is there a way that the BTS could retain information about previously present
packages, and avoid nagging tbm on follow-ups to existing bugs?

That could be done, though I think a bug should always be assigned to
at least one currently existing package. So perhaps the notification
should be something like this:

IF bug is assigned to at least one currently existing package
   and all packages assigned existed at some point THEN
   do nothing
ELSE
   bug tbm

However, in this case, there never was a binary package openldap2.3;
in etch, the source package was openldap2.3 which also built the
openldap binary package, so assigning it to only the openldap binary
package should be perfectly fine, and doesn't lose history. [If you
wanted to have it specifically assigned to both, then it should be
assigned to src:openldap2.3 and src:openldap... but I don't really see
the point.]


Don Armstrong

I think that sounds sane, yes.

Only because the BTS semantics for handling of source packages were changed
post-hoc and no effort was made to fix up the bug data to comply with the
newly-imposed rules.  But that's a bug report for another day.

In this particular case the benefit of recording that the bug was present in
all versions of a package only present in oldstable and earlier is minimal.
But in other cases (incl. future cases), there may be richer data available,
such as information about versions of the package that the bug is closed in
that may be useful to admins of systems that are desperately in need of
upgrade, or useful in the aggregate.

Cheers,

We never really handled source packages at all, actually. [We just
sort of assumed that a bug assigned to a package for which there
wasn't a corresponding binary package was assigned to a source package
with that name.] I think the only reasonable method is to go through
bug reports which are assigned to a binary package for which the
binary package doesn't exist, but the corresponding source package
does, and reassign them... but I haven't done that because I'm
terminally lazy.

Right, but those cases will still work if it was assinged to the
openldap binary package; doing a version-only found command will
automatically resolve the version to the appropriate source package,
assuming the binary package the bug is assigned to is correct. [The
only case where this would matter, I guess, is if in the future there
was an upload of the openldap2.3 source package which shipped an
openldap2.3 binary package which conflicted with the openldap binary
package provided by the >> 2.3 versions of openldap. Don't really see
that happening, though.]


Don Armstrong

Yes, this was a longstanding assumption that many BTS users relied on - and
that many still *do* rely on...

Yes, I agree :)

There's no openldap binary package and never has been?

Yeah; I'm /probably/ going to do this munging of non-existant binary
package -> existing source package of same name at reassign and submit
time in the future to fixup this practice without having to harass
maintainers every time they do it.

Ok. Once I get another clone of me working, this'll happen.

Heh. Stupid me. I mean slapd, of course! ;-)


Don Armstrong