On 13202 March 1977, Joachim Breitner wrote: >> - a PPAMAIN can have its full package set transferred into its base >> suite with one command, provided the base suite is configured to >> receive such transfers. (Currently we imagine only unstable will be >> configured for it, but other suites might gain this feature >> too). Only packages with versions NEWER than those existing in the >> base suite will be transferred. All version checks of the base suite >> must be fulfilled for the transfer to work. > with a big: „Yes, thanks in advance“ from the Haskell team. This will > allow us to keep the uninstallable count in unstable very low at all > times, even while we rebuild stuff for a new compiler.
Yep, one of the reasons for it (though not with haskell especially in mind, there are more packages that profit from it). > Feature suggestion: Optionally only allow the package set transferred to > unstable if all transferred packages are installable in the final set, > or similar checks as applied in the unstable → testing transition. That would mean having a kind-of-britney run, and only if that succeeds move it over. Should be doable, i think. >> - a PPAMAIN must have packages with unique versions which have to be >> greater than in the base suite. Package versions are global for the >> archive, so the ppaname has to be included in the version uploaded >> to the PPA. > What if it is decided by the maintainers of a certain package to do the > uploads always to a PPA first and from there, via the above command, to > unstable. Will it then be ok to use „normal“ version numbers? Good question. The thought behind this is that a ppa haskell1 can contain package debhelper as well as a ppa ruby42 can contain it. Both with different changes to it. Which should work, and the easiest way to ensure that is that each new upload to a ppa includes its ppaname. -- bye, Joerg Cabal: <lamont> Those people, who, when they do something currently outside of the official rules for behavior [your choice here] 1) are exempted from censure, or 2) (more accurately) by their actions define a new set of rules for acceptable behavior in such context. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip2x4hk0....@gkar.ganneff.de
