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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
