[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

splitting upstream

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

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)

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

Attachment: pgpXweeVmK4BG.pgp
Description: PGP signature

Reply to: