On Wed, Aug 25, 2004 at 03:28:29PM +0200, Frank K?ster wrote: > Andreas Barth <[EMAIL PROTECTED]> wrote in debian-devel: > > These packages are frozen, i.e. newer uploads to unstable won't go into > > testing. The official way is to upload also a package to testing. To upload > > a package to testing (or: testing-proposed-updates, this are just > > synonyms; tpu in short), it is necessary that the version number of the > > upload is smaller than the current installed package in unstable, and > > larger than the current installed package in testing. So, normally, you > > have to upload a package (directly or in whichever delayed you consider > > appropriate), and the version for testing in one more day delayed. > > Will this also be valid for non-base/standard packages, once everything > is frozen?
Yes, unless the sid version already moved on. Versions in testing cannot be higher than those of unstable, so this must be this way. > What version numbers are usually used? If it's no a NMU, does one upload > an artificially high version number (debian revision of -50 or so) to > unstable, just to be sure not to run out of maintainer-upload version > numbers for testing-proposed-updates? Or is it normal to use NMU version > numbers even for maintainer uploads to testing-proposed-updates? You never run out of maintainer version numbers, since can you always add parts. Suppose you're currentlat at -3, then you can of course still upload -4, -5 etc to sid, which is the common way. If you want a sarge backport of fixes to sid, use -3sarge1. If it's a Non-Maintainer backport, use -3.sarge1. With this method, one dot in maintainer revision means NMU (with the before-dot part being the latest MU), zero dots means MU, a property nice to have. Unfortunately, -3sarge1 sorts before -3.1, so if you want as maintainer to backport a NMU to sarge, you're out of luck for straightforward solutions. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl