On Thu, 24 Nov 2011 02:30:13 -0500, Michael Gilbert wrote:
On Thu, Nov 24, 2011 at 1:18 AM, Adam D. Barratt wrote:
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?
Dependency analysis is, yes, otherwise how would britney be able to
determine whether a package were installable? The section labelled
"dependency analysis" on migration/testing.pl, is not considered at all,
for reasons that will hopefully be clarified below if not already clear
enough.
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).
I've never mentioned anything about whether the package has previously
been in testing on a particular architecture. My point was that there
are _no kfreebsd-amd64 wine-unstable packages *in unstable*_ and never
have been, so there's no way at all that could be relevant to migration.
For clarity, the information:
wine-unstable has no old version in testing (trying to add, not
update)
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)
is derived from britney. The "dependency analysis" section is produced
by the script which produces the web pages, by parsing Packages and
Sources file. It's intended (I assume) to be useful, but it's purely
informational and often not that helpful.
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).
It doesn't matter, which might be part of the issue with this bug
report. :)
The only things that matter are going to be _above_ the "dependency
analysis" header, which are also things you could find in a combination
of grep-excuses (and therefore the PTS) and britney logs. In the case
of wine-unstable, those are the three lines I quoted above.
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.
Again, your conclusion is incorrect. :-(
Dependency analysis only derives its output from Sources + i386, which
is precisely _why_ it's showing ia32-libs-dev as unavailable. It's not
being mentioned because it's unavailable on kfreebsd-amd64, it's being
mentioned because it's unavailable _on i386_. If we annotated the
dependencies, it would say "wine-unstable[i386] depends on ia32-libs-dev
which is not available in testing", which doesn't seem like it would be
helpful.
It's also broken because it mixes build-dependencies and runtime
dependencies together - the binary packages produced by wine don't
depend on ia32-libs-dev - but that's a side issue.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/8bf9705d03ebeda861cc47060f1de...@mail.adsl.funky-badger.org
