Bug#649460: release.debian.org: improved architecture annotation in dependency analysis script/page
On Thu, Nov 24, 2011 at 1:18 AM, Adam D. Barratt wrote:
> On Wed, 2011-11-23 at 23:59 -0500, Michael Gilbert wrote:
>> On Mon, Nov 21, 2011 at 2:44 AM, Adam D. Barratt wrote:
>> > The reason that wine-unstable isn't migrating is listed at the top of
>> > the page:
>> >
>> > wine-unstable is not yet built on amd64: 1.1.34-1 vs 1.1.35-1 (missing 19 binaries)
>> > wine-unstable is not yet built on powerpc: 1.1.29-1 vs 1.1.35-1 (missing 18 binaries)
>>
>> Yes, I did see that, but none of that is relevant to this particular
>> issue, so I chose to exclude this extraneous info from my initial
>> report.
>
> I must admit I'm confused then.
>
> Your original mail said "wine is held back because of a lot of missing
> packages in testing, but only on kfreebsd-amd64", so I assumed that you
> were suggesting that such kfreebsd-amd64 issues were actually affecting
> the package's migration to testing - otherwise the fact that the
> packages aren't in testing is irrelevant.
>
> However, the package has never built on kfreebsd-amd64, so that's not an
> issue for testing. Regardless of whether the output of the migration
> page in terms of dependency analysis is optimal (which I'll quite
> happily admit it's not), the package is not being "held back" from
> testing because of anything on kfreebsd-amd64, so the reasons that the
> package actually *is* being "held back" don't seem at all extraneous,
> which was the point I was making.
Isn't the dependency analysis normally taken into account when testing
migratability? If not, it seems like that would be something very
useful to check (regardless of whether the package on that arch has
been in testing before or not).
Anyway, my point is that the current output makes it seem like a
missing ia32-libs-dev package is among the reasons the whole package
is being held back (again assuming the dependency analysis actually
matters). But that's not true since testing does have ia32-libs-dev
on amd64, so it shouldn't be a problem there. However, the dependency
analysis as is derives its output from all archs, but doesn't make
that clear, so it takes some work to figure out that the output in
this case comes from issues only on kfreebsd-amd64.
Best wishes,
Mike
Reply to: