The current source tarball contains code for 4 binaries. In future, upstream is likely to release three separate tarballs (possibly at different times) from the same CVS repository. One tarball matches the current source name and one of the existing binaries. The second tarball will provide the other 3 existing binaries and the third tarball will provide 4 new packages (a shared library, the -dev, the -doc and the -dbg). The first package will use that shared library as a dependency. So, foo-0.1.3.orig.tar.gz currently builds foo, bar-q, bar-p and bar-d. The next release will be: foo-0.2.0.orig.tar.gz (a lot smaller) bar-0.2.0.orig.tar.gz baz-0.2.0.orig.tar.gz foo.orig.tar.gz builds binary package foo. bar.orig.tar.gz builds binary packages bar-q, bar-p, bar-d and eventually bar-g (bar-g would be new). baz.orig.tar.gz builds libbaz0, libbaz-dev, libbaz0-dbg, libbaz-doc. foo build depends on libbaz-dev and will therefore depend on libbaz0. libbaz0 would then become a dependency of three other packages in due course, possibly four. One of those packages is already in Debian (containing duplicate code) so that will get smaller, another two will be new. I know baz will be NEW (and when it is ready, bar-gtk will also be NEW) but are bar-q, bar-p and bar-d NEW as far as the Debian incoming queue is concerned? All that has changed with bar-q, bar-p and bar-d is the name of the .orig.tar.gz (and .diff.gz) from foo to bar. I guess that's enough to make it NEW but it would be nice if bar didn't have to go through the queue when the only actual 'new' code is no more than a typical new upstream version. Is there anything else to watch? ALL the code has existed in the previous releases, it's only a migration of code. Does the upload of foo have to wait until bar has cleared NEW (if it does go into NEW)? foo is in Etch. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpuone1V5xM3.pgp
Description: PGP signature