[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: [Mass bug filing] Native vs. non-native packages consistency

Hi Steve,

>> 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[1] 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.


[1] http://lists.debian.org/debian-policy/2001/02/msg00140.html

Reply to: