[Ros-release] Troubles releasing a wet package to Hydro

[Jack O'Quin]

On Mon, Apr 15, 2013 at 11:11 PM, Tully Foote <tfoote at osrfoundation.org> wrote:
> On Mon, Apr 15, 2013 at 7:41 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
>> On Mon, Apr 15, 2013 at 8:40 PM, Tully Foote <tfoote at osrfoundation.org>
>> wrote:
> Sorry vcstools had not been propogated into raring. It's fixed now.  With
> those dependency issues "virtual package" is apt's way of saying does not
> exist.  Which is not really straight forward.

Yep, the Raring builds started working immediately.

The virtual package is Debian and Ubuntu's way of handling generic
dependencies. In this case, it needs Python but doesn't care whether
it's 2.7 or 3.x. We are going to need to deal with this, too. Their
general approach is to release separate packages for the two versions,
like python-yaml and python3-yaml.

>> >> But, isn't this the sort of error pre-release tests are intended to
>> >> find? Why did that also succeed? Is roslib getting installed there by
>> >> mistake or as a side-effect of some other package? How much does the
>> >> pre-release build differ from the binarydeb build?
>> >
>> > The prerelease does a lot more than the debbuilds.  It is doing the same
>> > as
>> > a devel job does, building and testing from source.  And afterwords it
>> > builds and tests from source all packages which depend on the requested
>> > package.  There's another test we could run which would actually test
>> > the
>> > debbuild process, but the debbuild process does not install the tests so
>> > you
>> > cannot run the tests after installing the debs which is not as helpful.
>>
>> Getting the dependencies exactly right in catkin is *difficult*. In
>> order not to release things that break the build (like I did), we need
>> an easy-to-run test to make sure the package builds and runs on a
>> system with only the packages it explicitly depends upon (directly or
>> indirectly). That is hard to do on a development system.
>>
>> I had naively expected the pre-release test to do that for me. When it
>> worked, I thought that meant I was finally ready to do the release.
>>
>> Perhaps your following suggestion can be developed into a solution for
>> this problem...
>
> So we talked about this a little bit and there's actually two tests we
> should be running.  First is the prerelease which will do like we do now and
> test from source against itself and reverse dependencies for regressions.
> The second is a predistribution test which will basically verify that the
> debbuild process will succeed. It will check these minimum requirements etc.
> This one in particular is hard because unless you are only doing the
> debbuild you will always have the core tools like roslib in your
> environment.  We'll try to develop these tests separately as they complete
> two different roles.

I agree completely. We really need both tests, and they should be
simple enough to run that we can reasonably expect maintainers to run
them before releasing a new package version.

>> > It's relatively simple to test the debian build process.  Checkout the
>> > branch specific to your current platform in the gbp.  Make sure you have
>> > installed all the dependencies listed in the debian/control file.  And
>> > call
>> > dpkg-buildpackage with -uc -us (to skip signing).  The deb files and
>> > .changes will pop out in the directory above.
>>
>> I tried this (see below). But, I don't see how running it would prove
>> that the list of dependencies is complete. I already have
>> ros-hydro-roslib installed on my development machine, so how is it
>> going to detect that missing dependency?
>
> Yes this usually won't detect undeclared dependencies unless you run it in a
> chroot. You can have this build the source deb and then invoke pbuilder,
> it's only a couple lines but then we're getting into basically the debbuild
> script so this can be wrapped up into the predistribution test above. Maybe
> even have bloom offer to run them for you.

Sounds good. Thanks for the assistance.
--
 joq