Hi Toshio,
On Thu, 2014-02-06 at 21:37 -0800, Toshio Kuratomi wrote:
> It all depends on the goals. If the goal is for an upstream to
> provide their own packages that you get from them to run on fedora
> then their method is probably fine.
Upstream doesn't provide rpms, only debs. Even the new bloom addition
only provides spec files as far as I can see, but I haven't tested it
out yet to be sure.
> If the goal is to submit to fedora then probably non-scl and
> installing to /usr is what's needed.
This is what we were working on till now. We picked ros-groovy as the
release we wanted to provide in Fedora and were packing it up with
various patches to make it install to /usr. However, at the time we made
this decision, SCLs weren't much in the picture and neither was the
Fedora.next system where we could have "rings" of application systems.
There wasn't anything else that could be done really.
> If the goal is to have parallel installed same versions then using
> scls may be the way to go. (But do note that there is a fair bit of
> overhead in terms of packaging to do this... but some portion of the
> effort carries over to future parallel versions.
Ideally, this is what we'd like to do, to be able to provide users with
all releases of ROS. For example, even at the lab I work in, some people
use ros-fuerte, some use ros-groovy (they have good support for the PR2
robot) and some have already moved on to ros-hydro. ROS upstream
intentionally choose to install packages into /opt/ so that users (most
of which are researchers) could run multiple releases in parallel.
I do understand that there's an overhead in maintaining multiple
releases. It's why we had chosen to pack up only one ROS release for
Fedora. However, with bloom generating spec files for us, this would
hopefully be manageable. If we don't have to modify upstream build files
to install to /usr, the work is *considerably* lessened too. (I'd expect
to have more people helping us too, since it's less work to package
stuff up if it's going into /opt straight away.)
Upstream recently informed me:
- With respect to the SCLs OSRF is now a registered LSB provider for
"ros" http://www.lanana.org/lsbreg/providers/providers.txt
I think SCLs are the way to go. ROS fits in perfectly here.
https://github.com/ros-infrastructure/bloom/pull/228
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
Hi,
Bloom, the ROS generator system has recently gotten support to generate
rpms[1]. At the moment, the author is simply putting releases
into /opt/ros/$ros-release and isn't making use of SCLs. Is this OK, or
should they use SCLs?
As you'll see from the ticket, I've already pointed him to SCLs, but
considering that he's already using /opt/ros/$ros-release, and not the
system directories, I'm wondering how using SCLs would be any different?
[1] https://github.com/ros-infrastructure/bloom/pull/228
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
TIL that there are around a thousand packages
in Fedora that include a file named jquery.js... [1]
Anyway it is good to see efforts to tackle these kinds of problems
with the Javascript and Web Assets Guidelines. :)
I want to ask if the packaging of grunt and jquery
blocks current package reviews of packages that bundle jquery.js?
Or can they proceed for now until jquery is actually packaged in Fedora?
Jens
ps It is going to be a long cleanup process to fix all those packages with bundled files.
[1] https://fedoraproject.org/wiki/Changes/Web_Assets#Web_application_packagers