Bug 452486 (stage)

This is just an informal review.

MUST items:
- Rpmlint output clean on the spec file and the source rpm file: ok
- Package name: ok
- Spec file name: ok
- Package license: ok
- Actual license: ok
- License file included: ok
- Spec file legible and in American English: ok
- Included source file matches upstream source: ok
- BuildRequires seem ok.
- No need to use %find_lang. ok
- /sbin/ldconfig called in %post and %postun: ok
- Package not relocatable: ok
- Owns its directories and files: ok
- No duplicate files in %files: ok
- Permissions set correctly with %defattr: ok
- rm -rf $RPM_BUILD_ROOT in %clean: ok
- Consistent macro use with $RPM_BUILD_ROOT: ok
- Package contains code: ok
- No large documentation: ok
- Headers in -devel package: ok
- Static libraries in -static package: ok
- Includes .pc files for pkgconfig, depends on pkgconfig: ok
- %{_libdir}/*.so goes in -devel package, %{_libdir}/*.so.* go in the main
package: ok
- Fully versioned dependency for the -devel subpackage: ok
- No .la files: ok
- rm -rf $RPM_BUILD_ROOT at the beginning of %install: ok
- Filenames are valid UTF-8: ok

- Builds ok; can't test since the dependencies aren't yet in Fedora 9. Building
a modified package without the player-devel dependency works fine.

May need a fix:
- Doesn't contain a .desktop file and doesn't tell why there is no need for one,
even though is a GUI application (uses Gtk).

Thanks for the quick review. Though this is a gtk application, everything in the
PSG (Player/Stage/Gazebo) framework more or less works from CLI. For, normally
stage or rather the libstageplugin is actually invoked by player by loading a
cfg file/simulation environment. And then stage starts off. Interaction occurs
through a client interface. So as obvious, cfg files etc can vary at each run of
player/stage which are required to be provided as options to the binaries. The
binaries provided solely by stage package also have similar application and
depends on .world files as options. The  gui is not yet got to the level of
taking care of all this, so practically there seems no feasible use of .desktop
file for stage. But if at all required something can be done with the example
.cfg files that comes with stage.

Hi Arindam. Some comments and questions:

- The plugin shouldn't be versioned. Can we prevent that? For now the Player plugin is at /usr/lib64/libstageplugin.so.1, but if you try to load it Player will only try libstageplugin.so (without .1 in the end). So only if the devel sub-package is installed the plugin can actually be loaded.
- There is a problem with the Player package with the plugin search path. We need to define a Plugin directory like /usr/lib/player which is used to store plugins. I will work on that for the Player package so that we can use it for Stage.
- Have you tried the new 3.0.1? Maybe we want to rename this package to stage2 and package the new version as stage?

(In reply to comment #3)
> - The plugin shouldn't be versioned. Can we prevent that? For now the Player
> plugin is at /usr/lib64/libstageplugin.so.1, but if you try to load it Player
> will only try libstageplugin.so (without .1 in the end). So only if the devel
> sub-package is installed the plugin can actually be loaded.

Well, this may call for merging of -devel branch with the main package. thoughts?

> - There is a problem with the Player package with the plugin search path. We
> need to define a Plugin directory like /usr/lib/player which is used to store
> plugins. I will work on that for the Player package so that we can use it for
> Stage.

yeah, i noticed the search path problems earlier while packaging stage...so what is its' status now? player cvs is up now...haven't got time to check these things..../me badly busy at the final leg of the GSoC project

> - Have you tried the new 3.0.1? Maybe we want to rename this package to stage2
> and package the new version as stage?

the last time i tried to build it failed miserably. they have lot of pending things to put in stage3, so as things become little stable with the upstream, i will update the srpm.

(In reply to comment #4)
> Well, this may call for merging of -devel branch with the main package.
> thoughts?
> 
[...]

I'm about to commit a patch (currently testing), which will use %{_libdir}/player as a plugin directory. There is one plugin coming with Player where I move the library file to the desired name in the new Player plugin directory and removed the symlinks. So this would probably what we want to do for now, you agree?

> the last time i tried to build it failed miserably. they have lot of pending
> things to put in stage3, so as things become little stable with the upstream, i
> will update the srpm.

I think that's a good decision. Let it stabilize a bit...

Updates for F-8/F-9 have been created. Get the builds from Koji as updates will take some time because of the infrastructure outages and switching to a new signing key.

F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=61379
F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=61301
Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=61382

Please see the Player spec at http://cvs.fedoraproject.org/viewvc/rpms/player/F-9/player.spec?revision=1.3&view=markup how to copy the plugins (see %install section, mv/rm commands just before the desktop-file-install lines.

It's been over six months now; was there ever an updated package, or should this ticket just be closed?

Closing after another week with no response.

*** This bug has been marked as a duplicate of bug 556346 ***