How to best handle one orig tarball with two source packages

If you want to create source-package for the sub-directory, you need to create separate versions. I suspect you want the embedded package name/version to indicate it originates from the master package.

launchpad once recognised the embedded/includes when creating packaging links between project series and distro packages, but the relationship is often confusing. The neon package is/was embedded into the tree of several projects. The packages for those projects either do not create a separate package for the embedded code, or created a package name like "neon-bluefish".

Oh, very interesting...

Is there a cannonical format for the "debian version" part of the version string to support having multiple source packages with the same name but one for the libraries and one for the example programs, without one package whose version is sorted as "more up-to-date" clobbering the "older" one? (Similar, I suppose, to how one can include the name of the targeted Ubuntu series in the version string and thus have multiple co-existing identically-named source packages.)

For example, (following the naming scheme of the library I'm working with) if my original tarball libfoo1.0-001.orig.tar.gz is to have multiple source packages, one for the libraries and one for the example program sub-directory, could I have the library package be libfoo1.0-001-1~quantal1 and the examples be in libfoo1.0-001-examples+1~quantal1, and not have the two clobber each other? Or perhaps there is a more cannonical naming scheme for this situation?

(BTW, the version number is in the library package name itself in this case because I need to support having multiple versions of the library installed simultaneously.)

Thanks!

Oops, sorry, I meant the names would be "libfoo1.0_001-1~quantal1" and "libfoo1.0_001-examples+1~quantal1" (I used a dash instead of an underscore.)

The dashes in the tarball are indeed problematic. The orig file uses an underscore to separate the package name from the version. The version may use a + or - to distinguish subtly different versions . The first number after ~ is the debian version. If the package is not published in debian the number is 0. "ubuntu" or the ubuntu series codename and version number is concatenated
    libfoo1.0_001.orig.tar.gz => libfoo1.0-001~0quantal1
    libfoo1.0_001+example.orig.tar.gz => libfoo1.0_001+examples~0quantal1

I think you might want difference release names though. "example" is not a version so much as permanent variation. If you want the ensure parallel installs, you want to move "example" into the name.
    example-libfoo1.0_001.orig.tar.gz => example-libfoo1.0_001~0quantal1
or
    libfoo-example1.0_001.orig.tar.gz => libfoo-example1.0_001~0quantal1

If I move the "example" into the name, though, that would imply I need the same source tarball under two different names, yes?

I was hoping to avoid the double-upload of the same tarball under two different names, but perhaps I cannot.

Alternatively, it is permissible in these situations to extract the examples subdirectory into a separate tarball on my end and upload that..? Unfortunately, though, that would seem to make the examples tarball no longer "pristine", I suppose...

If the source tarball is indeed identical, then you are correct to move "example" into the version.

Is there a special way to move "example" into the version such that launchpad will let both the "example" and non-"example" versions not override each other, i.e. do not treat one as a more recent version of the other?

I don't want to upload the "example" version, and then end up having the non-"example" version disappear...

Ah, okay, that's too bad!

Though from the look of it, after the upload, lauchpad is recognizing that the two differently named tarballs are actually the same, as I seem to have only the size of the tarball counted against me once. So that's nice!

Thanks DNS, that solved my question.