Re: Uploading NEW packages is ok
On Fri, May 21, 2010 20:38, Joachim Breitner wrote:
> I think most packages somehow involved in the transition are named,
> ether as binary or source, from
> http://release.debian.org/migration/testing.pl?package=haskell-platform
> but it might be that you actually need to follow all links and collect
> all further related packages.
fwiw, the list that britney generated as a result of my last test hint was:
agda, ftphs, haskell-arrows, haskell-data-accessor, haskell-datetime,
haskell-event-list, haskell-explicit-exception, haskell-filestore,
haskell-haxr, haskell-hsh, haskell-hstringtemplate, haskell-http,
haskell-markov-chain, haskell-midi, haskell-non-negative,
haskell-parallel, haskell-platform, haskell-quickcheck, haskell-recaptcha,
haskell-regex-compat, haskell-regex-posix, haskell-stream,
haskell-tagsoup, haskell-testpack, haskell-transformers,
haskell-unixutils, missingh
> Also, this page only lists i386 Dependency conflicts, so it might miss
> something.
It lists the first architecture on which a problem is detected (the list
is mostly alphabetical, but with i386 moved to the start).
> Now if any of these packages depends directly on directly on parsec3,
> uploading parsec3 (and thus rebuilding all depending packages) will set
> back the transition.
In general uploading a new version of a package not directly involved in
the transition /shouldn't/ be an issue.
However, if either of the following conditions is met, it is:
a) any of the packages involved depend on a version of the package which
is not currently in testing, and therefore need to transition together
with the package
b) the upload implies updates (either sourceful or via binNMUs) to
packages involved in the transition which in turn lead to a dependency on
a version of the package not currently in testing; sourceful updates would
also imply additional waiting time for the source.
There's also the potential for either of the above to occur via chains of
packages - e.g. package A which is in the transition depends on a newer
version of B, which is not in the transition; C is updated requiring a
binNMU of B causing it to depend on the newer version of C.
If memory serves, updates to haskell packages tend to result in binNMUs
being needed to their reverse dependencies? (i.e. "b" above)
Regards,
Adam
Reply to: