Re: Re: [Mass bug filing] Native vs. non-native packages consistency
>> Feel free to point me to false positives, as I haven't checked every
>> single one of them. I know that some of them already have respective
>> bugs filed against them.
> Indeed, at least some of these *are* false positives; there is nothing
> that prohibits the use of dashes in native version numbers [...]
Right, thanks for pointing that out. The Debian native package state and
Debian revisions are currently not directly connected. However, there
were discussions in the past about enforcing that.
Some DDs backed it while one (major;) other described his personal
packaging style as not suitable for that. However, his argument that
katie already detects when packages are alternately uploaded "native"
and "non-native" is not valid, since it doesn't/didn't work, see rscheme
and queue (just 2 random packages from "the list").
> [...] so I don't really think it's appropriate to mass-file bugs
> against packages which appear to be missing .diff.gz's until they've
> been verified individually.
Of course, I wouldn't just script 300+ bug openings automatically but
work on them individually.
A general criterion for opening a bug would be that there is a suitable
upstream package/tarball available that would be suitable as for the
general orig.tar.gz case, and/or that the package was non-native before
and one of the last uploads turned it to native by missing the orig.tar.gz.
> However, noting that you've managed to tag large
> numbers of core kernel packages as false-positives
I was well aware that the list includes some holy cows. ;-) Therefore, I
asked first. (Well, would have done that anyway.)
However, I consider most kernel packages you listed as legacy Debian
kernel packaging style.