Re: [Ros-release] Fuerte hudson builds failing

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Jack O'Quin
Date:  
To: ben.pitzer
CC: ros-release
Subject: Re: [Ros-release] Fuerte hudson builds failing
On Thu, Mar 1, 2012 at 1:42 AM, Benjamin Pitzer <> wrote:

> Ok, that's what I thought. I added our deps to the database today.
>
> I'm a little confused about the naming conventions in the database. There
> are at least three different schemes for system libraries, e.g.:
>
> libjpeg
> libdc1394-dev
> jasper
>
> and I also see some meta entries such as
>
> opengl
> ffmpeg
>
> which seem to contain multiple dependencies. If this will become the central
> database for all released stacks I would suggest to clean this up and keep a
> unified naming system. Otherwise this will become a mess and it will be
> difficult to check if a particular dependency already exists.


+1; this deserves some discussion.

* We depend on the `*-dev` packages for source builds, but not for
binary installs. Which should be specified? Should we pull in the
development package anyway for binary installs? (I believe that is
currently the case.)

* In most cases, renaming a system-wide rosdep key deserves some sort
of tick-tock with deprecation in one release and removal in the next.
Presumably meta-entries can provide two names simultaneously during
the overlap period. I can't think of a way to issue a deprecation
message, however. At least, that allows externally-maintained
repositories to build the same source code on both Electric and
Fuerte. That is important to people like me.

* Since these are system dependencies, I suggest adopting names
similar to the corresponding Ubuntu package names. Although other
packaging systems use different names, that at least provides a
canonical list that anyone can guess.

* For complicated dependencies like OpenCV, PCL and Qt, meta-entries
are a good idea. It should still be possible to depend on subsets of
those entire sets of libraries. For example, we want packages to be
able to use pcl_common without pulling in every single PCL library.
--
 joq