On Wed, Apr 22, 2015 at 3:50 PM, Jochen Sprickerhof via ros-users <ros-users@lists.ros.org> wrote:

* William Woodall <william@osrfoundation.org> [2015-04-22 15:12]:
> At the end of the day, we're looking for someone to take responsibility for
> it, no matter how it is distributed. So to me the distribution mechanism is
> up for discussion.

Ok, before this is getting philosophical, here you go (took me like 5min ;) ):

https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/ubuntu/for-ros

That's great! I don't mean to insight a flamewar.

I do want to reiterate what Tully said "[we are looking for someone who is] willing to setup a PPA on Launchpad and maintain a backport". The "and maintain a backport" is the part that we're most interested in. If you're offering to do that then that's awesome, otherwise we still someone to claim it. Maybe someone can help by co-owning the responsibility.

> On Wed, Apr 22, 2015 at 2:34 PM, Jochen Sprickerhof via ros-users <
> ros-users@lists.ros.org> wrote:
> I don't see a good reason for us to duplicate the functionality of PPA's.
> I'm not experienced using them (PPA's), is there a compelling reason not to
> use them?

In theory, you can provide updated versions of packages through
packages.ros.org, would wouldn't be available to compile against on the
PPA. But basically PPAs are not much more than outobuilders, so actually
you do provide the functionality of it already only with a different
interface.

> We provide REP-136 for this: http://www.ros.org/reps/rep-0136.html

Sorry, but that's by far not as powerfull as debhelper or other
packaging systems. Also, I really think we should not duplicate already
existing packaging tools.

Again, I don't want to start an argument, I just wanted clear up some misconceptions that bloom replaces git-buildpackage or debhelper in someway.

Both REP-136 packages and normal ROS packages use debhelper under the hood and bloom lets you modify the contents of all of your files in the `debian` folder, including the dephelper parts. For example:

- A ROS package rviz:

- debhelper: https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/rules#L3

- git-buildpackage config file: https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/gbp.conf

- A REP-136 package stage:

- debhelper: https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/rules#L3

- git-buildpackage config file: https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/gbp.conf

The only thing bloom does it try to give reasonable default files based on the portable information in the package.xml. The build farm invokes git-buildpackage to make source debs and that in turn invokes the rules file (which is Makefile) and that uses debhelper.

Our main goal with the build farm is make it as easy as possible for users to get from source to an installable deb, and not necessarily to release non-ROS packages as source debs. That being said if you see ways to accomplish both I assure you we're open to discussing that.

> On a side note, what do you need a dput interface for? I guess uploading
> hand crafted debs?

And source debs, that's how it's usually done.

We use dput as well, but I'm not sure what end users would use it for. We can't provide push access to our package repository without reviewing incoming packages. For us that's what rosdistro does, you tell us where it is (the source), and if we approve the farm goes and gets it. That's a pretty common model for public build farms.

> > I guess we would only need to relax some of
> > the awakward bloom assumptions in there.
>
> Can you explain what you mean? The output of bloom can be built (is built)
> with git-buildpackage and though by default it installs into a ROS prefix
> of `/opt/ros/<rosdistro>` it can be used to make debs that go into `/usr`
> as well.

Martin and I have looked into pushing normal git-buildpackge repos into
the ROS autobuilders, but from the code it looked like there where quite
some places where it assumes a bloom generated one. I haven't tried it
though.

Well I would like to remove any barriers that you can find and point out, but we've designed the system to be quite flexible. Often I find it is a matter of not knowing how to do it rather than it cannot be done. Please ask questions when you run into road blocks.

Cheers Jochen

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users

William Woodall

ROS Development Team

william@osrfoundation.org

http://wjwwood.io/