On Tue, 2012-07-24 at 15:08 -0700, Dirk Thomas wrote: 
> The subfolder under /etc/ should just be called "ros' (rathen than with a distro suffix).
> Why?
> If "etc" is located under /opt/ros/DISTRO/ the suffix is not necessary.
> If "etc" is located in the root there seems to be no reasonable way to install two different distros at the same time (without one being in a non-standard place like /opt/...).

If ROS is being started at bootup by Upstart it seems to me that the
config files don't belong in /opt

So, I'm referring explicitly to the system /etc located in the root
directory. Most Ubuntu systems
have /etc/python, /etc/python2.6, /etc/python3.1 so I don't think it is
unreasonable to use /etc/ros, /etc/ros-fuerte, /etc/ros-groovy. Also I
like that if we have a symlink from /etc/ros to /etc/ros-fuerte it would
make it easy to switch the config to groovy by changing the symlink.



> On 24.07.2012 13:23, Bill Morris wrote:
> > I have been working on some ideas for structuring the /etc/ros directory
> >
> > README
> >    The information below
> >
> > /etc/ros/network.conf
> >    A file that contains the shell environment settings for the network
> >      ROS_INTERFACE=wlan0
> >      ROS_IP=192.168.1.101
> >
> > /etc/ros/robot.launch
> >    Primary Startup Launch file loaded at bootup
> >
> > /etc/ros/conf.d
> >    Additional launch files loaded at bootup
> >
> > /etc/ros/urdf
> >    URDF model of the robot
> >
> > /etc/ros/sys
> >    The system files can be symlinked to this directory
> >    Upstart script
> >      /etc/init/ros.conf -> /etc/ros/sys/ros.conf
> >    udev rules
> >      /etc/udev/rules.d/50-usb-serial-port-assignment.rules
> > -> /etc/ros/sys/50-usb-serial-port-assignment.rules
> >
> > /etc/ros/setup.[sh|bash|zsh]
> >    This can be copied or symlinked to /opt/ros/<distro>
> >
> > By default a new install would have a directory
> > /etc/ros-<distro> (ie. /etc/ros-fuerte) that would have the default
> > versions of all of these files.
> > /etc/ros would then be symlinked to /etc/ros-<distro>
> >
> > The user could remove the symlink and make their own local changes
> > that would not be overwritten when new versions of the debian packages
> > are pushed out. This would also allow autoconfiguration scripts to
> > remove the sym link to save the original working configuration from
> > being overwritten.
> >
> > On Tue, 2012-07-24 at 18:30 +0200, Lorenz Mösenlechner wrote:
> >> Hi,
> >>
> >> I remember a discussion on that before Fuerte was released. Wasn't it
> >> even decided that roscreate-stack should re-appear?
> >>
> >> I think creating a new REP should be best. I'd like to see everything
> >> moved into <prefix>/lib and maybe put into a sub-directory ros. I.e.:
> >> /opt/ros/<distro>/lib/ros/<stack>/<package>.
> >>
> >> Lorenz
> >>
> >> On Tue, Jul 24, 2012 at 6:23 PM, Piyush <piyushk@gmail.com> wrote:
> >>> On Tue, Jul 24, 2012 at 9:59 AM, Jonathan Bohren
> >>> <jonathan.bohren@gmail.com> wrote:
> >>>> On Tue, Jul 24, 2012 at 4:35 PM, Jack O'Quin <jack.oquin@gmail.com> wrote:
> >>>>>
> >>>>> We need to resolve some fundamental build and filesystem layout issues
> >>>>> in time for Groovy.
> >>>>>
> >>>>> There are basic problems with REP-0122 that we were not able to fix in
> >>>>> time for Fuerte. To me, the biggest issue is placing binary files
> >>>>> under the "share" directory. But, there are others mentioned in the
> >>>>> REP, itself:
> >>>>>
> >>>>>   http://www.ros.org/reps/rep-0122.html#future-work
> >>>>>
> >>>>
> >>>> I know this is slightly off-topic, but now that you bring this up, I always
> >>>> felt that the removal of roscreate-stack was overkill. If it's worth
> >>>> anything, I think it should be brought back. It doesn't need to deal with
> >>>> dependencies, but it's useful just to not have to copy the CMakeLists,
> >>>> Makefile, and stack.xml from a stack I've already created.
> >>>
> >>> +1 for reintroducing roscreate-stack without dealing with dependencies
> >>>
> >>>>
> >>>> One important thing I'd like people to keep in mind when discussing the
> >>>> install behavior is that most ROS development environments have tons of
> >>>> non-installed packages. The package semantics were really designed for that
> >>>> use-pattern and it would be unfortunate if installation-behavior changes
> >>>> diminished the speed and flexibility that the uninstalled stack/package
> >>>> semantics provide.
> >>>>
> >>>> -j
> >>>>
> >>>> _______________________________________________
> >>>> ros-users mailing list
> >>>> ros-users@code.ros.org
> >>>> https://code.ros.org/mailman/listinfo/ros-users
> >>>>
> >>> _______________________________________________
> >>> ros-users mailing list
> >>> ros-users@code.ros.org
> >>> https://code.ros.org/mailman/listinfo/ros-users
> >>>
> >>
> >>
> >>
> >
> 

-- 
Bill Morris <bill@iheartengineering.com>
I Heart Engineering
http://www.iheartengineering.com
<3