From: Rich M. <jp...@gm...> - 2009-12-20 22:59:02
|
I've been working on packaging Stage 3.2.2 for Fedora, and I am running into a few trouble spots. Stage comes with several plugin libraries for different behaviors, which by default install themselves into the system's library directory. These libraries are dlopened within Stage, and aren't named with the lib___.so convention. Packages also generally have libraries with versioned filenames in the base package, and the plain .so files go in the -devel package. Also, if the libraries are dlopened, there's no need for them to be on the system library search path. Packages like gstreamer, which make use of plugin libraries, will make a separate folder in the library search path (like /usr/lib/gstreamer) and put plain .so files in these directories. Then they'll make packages like gstreamer-plugins-* to add and remove plugins to the program as needed. I'm thinking that Player and Stage should create folders like /usr/lib/player-3 and /user/lib/stage-3, and look for plugin libraries in these folders by default. This will allow Player and Stage to create plugin libraries without versioning in the filename, and put the libraries in a standard place that isn't just lumped in with the system libraries. Stage could put (lib)stageplugin.so in /usr/lib/player-3, etc. This could also help when a plugin is compiled against the wrong version of Player, Player won't attempt and fail to load it. Player could scan the /usr/lib/player-3 directory when its first run and determine which drivers are present, which could be used to populate the list of drivers that have been "Compiled into Player". Users can use this feature to add their own drivers to the default installation, and Player could even warn if an incompatible plugin was detected on its search path. Looking forward (from a packaging perspective), this change could allow libplayerdrivers.so to be split up into several pieces. As it stands, installing Player means bringing in every dependancy Player was compiled against (which is quite a lot of packages). This is not ideal on small or embedded systems, which need one or two drivers at most. Further, one might just want the Player server without any drivers at all, since he or she is only using their own plugin drivers. As it stands, users would have to compile Player themselves and choose which drivers to add or remove, there's no way the packaging process couldn't help this along. This architecture change would let someone install the Player server without any additional dependencies. Common lightweight drivers like readlog, writelog, dummy, lasertoranger, etc. should probably be kept with Player, but the rest could be split up by function, dependencies, supported OS, etc. These categories could be managed by CMake, or through the packaging process (cmake would make it easier to maintain consistency across distributions). I know this is a large architectural change, but as Player grows (in size and popularity), it doesn't make sense to build so many drivers when a user won't necessarily need them. It will also help make Player packages for popular distributions more useful, and allow users more customization without the hassle of compiling Player on their own. Adding Player and Stage packages to popular distributions will also help make he project more accessible to newcomers. I'm happy to help make this a reality for Player and Stage, I'm wondering if this is a direction the project would like to go. Rich Mattes |
From: Richard V. <va...@sf...> - 2009-12-22 20:01:42
|
These are sensible proposals. I always install P and S into a special directory rather than going with the default, so I have not noticed these usability issues. I will make the changes to Stage to place plugins in a dedicated directory. I'll leave it to Geoff and Brian to comment on the breaking up of libplayerdrivers, except to say that this is in line with the current plan for the future of Player. Richard/ On Sun, Dec 20, 2009 at 2:58 PM, Rich Mattes <jp...@gm...> wrote: > I've been working on packaging Stage 3.2.2 for Fedora, and I am running > into a few trouble spots. Stage comes with several plugin libraries for > different behaviors, which by default install themselves into the > system's library directory. These libraries are dlopened within Stage, > and aren't named with the lib___.so convention. Packages also generally > have libraries with versioned filenames in the base package, and the > plain .so files go in the -devel package. Also, if the libraries are > dlopened, there's no need for them to be on the system library search path. > > Packages like gstreamer, which make use of plugin libraries, will make a > separate folder in the library search path (like /usr/lib/gstreamer) and > put plain .so files in these directories. Then they'll make packages > like gstreamer-plugins-* to add and remove plugins to the program as needed. > > I'm thinking that Player and Stage should create folders like > /usr/lib/player-3 and /user/lib/stage-3, and look for plugin libraries > in these folders by default. This will allow Player and Stage to create > plugin libraries without versioning in the filename, and put the > libraries in a standard place that isn't just lumped in with the system > libraries. Stage could put (lib)stageplugin.so in /usr/lib/player-3, > etc. This could also help when a plugin is compiled against the wrong > version of Player, Player won't attempt and fail to load it. Player > could scan the /usr/lib/player-3 directory when its first run and > determine which drivers are present, which could be used to populate the > list of drivers that have been "Compiled into Player". Users can use > this feature to add their own drivers to the default installation, and > Player could even warn if an incompatible plugin was detected on its > search path. > > Looking forward (from a packaging perspective), this change could allow > libplayerdrivers.so to be split up into several pieces. As it stands, > installing Player means bringing in every dependancy Player was compiled > against (which is quite a lot of packages). This is not ideal on small > or embedded systems, which need one or two drivers at most. Further, > one might just want the Player server without any drivers at all, since > he or she is only using their own plugin drivers. As it stands, users > would have to compile Player themselves and choose which drivers to add > or remove, there's no way the packaging process couldn't help this > along. This architecture change would let someone install the Player > server without any additional dependencies. Common lightweight drivers > like readlog, writelog, dummy, lasertoranger, etc. should probably be > kept with Player, but the rest could be split up by function, > dependencies, supported OS, etc. These categories could be managed by > CMake, or through the packaging process (cmake would make it easier to > maintain consistency across distributions). > > I know this is a large architectural change, but as Player grows (in > size and popularity), it doesn't make sense to build so many drivers > when a user won't necessarily need them. It will also help make Player > packages for popular distributions more useful, and allow users more > customization without the hassle of compiling Player on their own. > Adding Player and Stage packages to popular distributions will also help > make he project more accessible to newcomers. I'm happy to help make > this a reality for Player and Stage, I'm wondering if this is a > direction the project would like to go. > > Rich Mattes > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University |