Converting a third party package into a regular ROS package.

68 views
Skip to first unread message

Piyush

unread,
Jan 28, 2015, 1:51:18 PM1/28/15
to ros-sig-b...@googlegroups.com
Hey folks,

For Indigo, I've forked libfreenect and have modified it to be a regular ROS package. In the past this package has been released as third party, but I was finding that a bit difficult to maintain.

Is the easiest solution to create a separate release repository for the regular ROS release and change the release repository location for Indigo? I don't want to necessarily mess with the current release repository as I would like to leave the Hydro release as is (i.e. third party). Or is the current release repo easily salvageable?

Thanks!
Piyush

William Woodall

unread,
Jan 28, 2015, 2:03:26 PM1/28/15
to ros-sig-b...@googlegroups.com
Hi Piyush,

Simply do the normal release process with the ROS package version of the it for Indigo. You can use the same release repository as long as you haven't already released the third party version for that ROS distribution.

If you have already released the third party version for Indigo, then you might want to just create a new release repository, but it might work to just update the track for indigo and do another release too.

Let me know if you have any trouble, special cases sometimes have snags.

--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-buildsystem/CAHBO3%3D52FnwpwR3CRedpYJ6SbOOsrHh9o4JTCSu9Tv8Fhg-0iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
William Woodall
ROS Development Team

Piyush

unread,
Jan 28, 2015, 2:09:57 PM1/28/15
to ros-sig-b...@googlegroups.com
Thanks William. I should have mentioned that it's been released in Indigo once already. I'll just go with a separate release repository then, as I don't think I'll have time to track down issues with the release process.

Could you create a libfreenect-ros-release repo in ros-drivers-gbp and allow the freenect-maintainers team to have admin privileges for that repo?

Thanks!
Piyush



William Woodall

unread,
Jan 28, 2015, 2:18:27 PM1/28/15
to ros-sig-b...@googlegroups.com

Piyush

unread,
Jan 29, 2015, 12:28:10 AM1/29/15
to ros-sig-b...@googlegroups.com
Hey William,

Thanks for making the repo. The first issue I've hit is that https://github.com/ros/rosdistro/blob/master/indigo/distribution.yaml has an entry for libfreenect which bloom picks up, and it doesn't give me an option to use the new release repository. Do I first need to submit a pull request that updates this file to the new release repository (and if so, what version should I set it too)?

Thanks!
Piyush

William Woodall

unread,
Jan 30, 2015, 2:10:22 PM1/30/15
to ros-sig-b...@googlegroups.com
Yeah, if you want to use bloom-release and change the release repository without changing the repository name, then you'll need to remove it first. Theoretically there is no reason why bloom-release couldn't take an optional repository url argument which would let you override this.

I can try to modify bloom and let you see if that works if you're willing to wait and try a non-released version of bloom.


For more options, visit https://groups.google.com/d/optout.

Mike Purvis

unread,
Jan 30, 2015, 2:12:28 PM1/30/15
to ros-sig-b...@googlegroups.com
I would find such an argument useful for situations where we're blooming a patched version of a public package into a private rosdistro. I know that's not something to do lightly, and we avoid it where possible, but it does come up.

William Woodall

unread,
Jan 30, 2015, 2:17:19 PM1/30/15
to ros-sig-b...@googlegroups.com
Mike, I guess you mean that you are also using a different ROSDISTRO_INDEX_URL which points to your private rosdistro, as changing the release repository url will still override the existing entry in our ros/rosdistro distribution.yaml file unless you do that.


For more options, visit https://groups.google.com/d/optout.

Mike Purvis

unread,
Jan 30, 2015, 3:01:28 PM1/30/15
to ros-sig-b...@googlegroups.com
Right now, it's an awkward dance— for packages with entirely public dependencies, it's easier to run bloom-release with the default ROSDISTRO_INDEX_URL, opt out of the pull request, then set ROSDISTRO_INDEX_URL and re-run with --pull-request-only (or manually edit the internal rosdistro repo).

For packages with a lot of private dependencies, I tend instead to maintain a rosdep file of mappings. I keep meaning to write a little tool to generate that automatically (as discussed here), but it seems like the next-generation rosdistro scripts have more explicit support for overlaying distros. Maybe now is a good time to ask for some commentary on that as far as the state it's in, when it will be released, usable, etc etc.

M.

William Woodall

unread,
Jan 30, 2015, 3:26:16 PM1/30/15
to ros-sig-b...@googlegroups.com
@Piyush You can give this branch a try:


There are two new options, --override-release-repository-url and --override-release-repository-push-url. You would need to pass at least the `--override-release-repository-url`  and optionally the `--override-release-repository-push-url` if you need a different push url than what the repository has in it.

@Mike I'm not sure exactly what part of the puzzle you are talking about. I think the closest thing to what you're talking about is the new build farm which has been designed with multi rosdistro release files in mind. That is getting wrapped up now, I would imagine we'll start to roll out test farms for Jade and Indigo soonish. I'll defer to Tully or Dirk on that though.


For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages