<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 22, 2015 at 3:50 PM, Jochen Sprickerhof via ros-users <span dir="ltr"><<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* William Woodall <<a href="mailto:william@osrfoundation.org">william@osrfoundation.org</a>> [2015-04-22 15:12]:<br>
<span class="">> At the end of the day, we're looking for someone to take responsibility for<br>
> it, no matter how it is distributed. So to me the distribution mechanism is<br>
> up for discussion.<br>
<br>
</span>Ok, before this is getting philosophical, here you go (took me like 5min ;) ):<br>
<br>
<a href="https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/ubuntu/for-ros" target="_blank">https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/ubuntu/for-ros</a></blockquote><div><br></div><div>That's great! I don't mean to insight a flamewar.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<span class=""><br>
> On Wed, Apr 22, 2015 at 2:34 PM, Jochen Sprickerhof via ros-users <<br>
> <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a>> wrote:<br>
</span><span class="">> I don't see a good reason for us to duplicate the functionality of PPA's.<br>
> I'm not experienced using them (PPA's), is there a compelling reason not to<br>
> use them?<br>
<br>
</span>In theory, you can provide updated versions of packages through<br>
<a href="http://packages.ros.org" target="_blank">packages.ros.org</a>, would wouldn't be available to compile against on the<br>
PPA. But basically PPAs are not much more than outobuilders, so actually<br>
you do provide the functionality of it already only with a different<br>
interface.<br>
<span class=""><br>
> We provide REP-136 for this: <a href="http://www.ros.org/reps/rep-0136.html" target="_blank">http://www.ros.org/reps/rep-0136.html</a><br>
<br>
</span>Sorry, but that's by far not as powerfull as debhelper or other<br>
packaging systems. Also, I really think we should not duplicate already<br>
existing packaging tools.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- A ROS package rviz:</div><div> - debhelper: <a href="https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/rules#L3">https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/rules#L3</a></div><div> - git-buildpackage config file: <a href="https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/gbp.conf">https://github.com/ros-gbp/rviz-release/blob/debian/indigo/trusty/rviz/debian/gbp.conf</a></div><div>- A REP-136 package stage:</div><div> - debhelper: <a href="https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/rules#L3">https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/rules#L3</a></div><div> - git-buildpackage config file: <a href="https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/gbp.conf">https://github.com/ros-gbp/stage-release/blob/debian/indigo/trusty/stage/debian/gbp.conf</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> On a side note, what do you need a dput interface for? I guess uploading<br>
> hand crafted debs?<br>
<br>
</span>And source debs, that's how it's usually done.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> > I guess we would only need to relax some of<br>
> > the awakward bloom assumptions in there.<br>
><br>
> Can you explain what you mean? The output of bloom can be built (is built)<br>
> with git-buildpackage and though by default it installs into a ROS prefix<br>
> of `/opt/ros/<rosdistro>` it can be used to make debs that go into `/usr`<br>
> as well.<br>
<br>
</span>Martin and I have looked into pushing normal git-buildpackge repos into<br>
the ROS autobuilders, but from the code it looked like there where quite<br>
some places where it assumes a bloom generated one. I haven't tried it<br>
though.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers Jochen<br>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">William Woodall<div>ROS Development Team</div><div><a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a></div><div><a href="http://wjwwood.io/" target="_blank">http://wjwwood.io/</a></div></div></div>
</div></div>