The script-templates are really just data, so they should go under %{datadir}/fedora-ds
Created attachment 146493 [details] diffs
Created attachment 146494 [details] new diffs
looks sane to me
Looks good.
Created attachment 146578 [details] cvs commit log Reviewed by: nkinder, dennis (Thanks!) Files: see diff Branch: HEAD Fix Description: Just change sysconfdir to datadir in both the Makefile.am (which controls where the files are put during installation) and in create_instance.c (which controls where instance creation looks for the templates to use them to create the real scripts). Platforms tested: RHEL4 Flag Day: no Doc impact: no
Thank you, Rich, for fixing the template file location. Now, how about the spec file fedora-ds.spec? 1) removing these 2 lines mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} mv $RPM_BUILD_ROOT%{_sysconfdir}/%{name}/script-templates $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} 2) and adding the template files to the %files section? %{_datadir}/%{name}/template-* I'm using the spec file fedora-ds/RHEL-4/fedora-ds.spec checked in in the CVS :gserver:cvs.devel.redhat.com:/cvs/dist for the nightly build.
(In reply to comment #6) > Thank you, Rich, for fixing the template file location. > Now, how about the spec file fedora-ds.spec? > 1) removing these 2 lines > mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} > mv $RPM_BUILD_ROOT%{_sysconfdir}/%{name}/script-templates > $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} > 2) and adding the template files to the %files section? > %{_datadir}/%{name}/template-* > > I'm using the spec file fedora-ds/RHEL-4/fedora-ds.spec checked in in the CVS > :gserver:cvs.devel.redhat.com:/cvs/dist for the nightly build. Sure. I'm doing a test build right now to make sure it works, once that's done I'll commit it.
I'm trying to start the server installed from the rpm built with the fedora-ds.spec you checked in. Now, the script template files are in /usr/share/fedora-ds/script-templates. (Thanks!) Next, the server fails to start since the libraries (plugins and 4 libraries in /usr/lib/fedora-ds) do not have its symlink <libname>.so pointing to <libname>.so.0.0.0 (note: there is <libname>.so.0 pointing to <libname>.so.0.0.0) Fedora-Directory/1.1 B2007.025.2240 <host>:<port> (/dev/shm/DS7.2-4024/server/slapd-laputa) [25/Jan/2007:15:27:07 -0800] - Netscape Portable Runtime error -5977: //usr/lib/fedora-ds/plugins/libpwdstorage-plugin.so: cannot open shared object file: No such file or directory [25/Jan/2007:15:27:07 -0800] - Could not open library "//usr/lib/fedora-ds/plugins/libpwdstorage-plugin.so" for plugin SSHA [25/Jan/2007:15:27:07 -0800] - The plugin entry [cn=SSHA,cn=Password Storage Schemes,cn=plugins,cn=config] in the configfile /dev/shm/DS7.2-4024/server/slapd-laputa/dse.ldif was invalid [25/Jan/2007:15:27:07 -0800] startup - The configuration files in directory /dev/shm/DS7.2-4024/server/slapd-laputa could not be read or were not found. Please refer to the error log or output for more information. I noticed that the *.so files are in fedora-ds-devel... That is, to start the server, fedora-ds-devel must be installed, as well? That sounds a little odd to me... Is that how you run/test the DS7.2? $ rpm -ql fedora-ds-devel /usr/lib/fedora-ds/libback-ldbm.so /usr/lib/fedora-ds/libds_admin.so /usr/lib/fedora-ds/libns-dshttpd.so /usr/lib/fedora-ds/libslapd.so /usr/lib/fedora-ds/plugins/libacl-plugin.so /usr/lib/fedora-ds/plugins/libattr-unique-plugin.so /usr/lib/fedora-ds/plugins/libchainingdb-plugin.so /usr/lib/fedora-ds/plugins/libcollation-plugin.so /usr/lib/fedora-ds/plugins/libcos-plugin.so /usr/lib/fedora-ds/plugins/libdes-plugin.so /usr/lib/fedora-ds/plugins/libdistrib-plugin.so /usr/lib/fedora-ds/plugins/libhttp-client-plugin.so /usr/lib/fedora-ds/plugins/libpam-passthru-plugin.so /usr/lib/fedora-ds/plugins/libpassthru-plugin.so /usr/lib/fedora-ds/plugins/libpresence-plugin.so /usr/lib/fedora-ds/plugins/libpwdstorage-plugin.so /usr/lib/fedora-ds/plugins/libreferint-plugin.so /usr/lib/fedora-ds/plugins/libreplication-plugin.so /usr/lib/fedora-ds/plugins/libretrocl-plugin.so /usr/lib/fedora-ds/plugins/libroles-plugin.so /usr/lib/fedora-ds/plugins/libstatechange-plugin.so /usr/lib/fedora-ds/plugins/libsyntax-plugin.so /usr/lib/fedora-ds/plugins/libviews-plugin.so /usr/share/doc/fedora-ds-devel-1.1.0 /usr/share/doc/fedora-ds-devel-1.1.0/EXCEPTION /usr/share/doc/fedora-ds-devel-1.1.0/LICENSE
Right. The usual convention is that the -devel package has the libraries libname.so which is a symlink to the 'real' lib libname.so.x.y.z, which is supplied by the regular package. What should happen is that at build time, you link against the library libname.so, and the linker is supposed to magically figure out that it can use libname.so or libname.so.x or libname.so.x.y or libname.so.x.y.z to resolve that dependency at runtime. The plugins are a special case though, because they are loaded directly by the application via dlopen and not by the dynamic linker, so we should probably have just a libname-plugin.so file in the fedora-ds package and remove them from the -devel package.
It looks we also need ot have libback-ldbm.so in fedora-ds, since it's yet another plugin... Fedora-Directory/1.1 B2007.026.034 laputa:17353 (/dev/shm/DS7.2-5356/server/slapd-laputa) [25/Jan/2007:16:55:04 -0800] - Netscape Portable Runtime error -5977: //usr/lib/fedora-ds/libback-ldbm.so: cannot open shared object file: No such file or directory [25/Jan/2007:16:55:04 -0800] - Could not open library "//usr/lib/fedora-ds/libback-ldbm.so" for plugin ldbm database [25/Jan/2007:16:55:04 -0800] - Unable to load plugin "cn=ldbm database,cn=plugins,cn=config" $ rpm -ql fedora-ds | egrep libback-ldbm /usr/lib/fedora-ds/libback-ldbm.so.0 /usr/lib/fedora-ds/libback-ldbm.so.0.0.0
Ok. I just moved all of the .so files into the base package.
Do we even want to have versioned libraries? They are all currently version "0.0.0". Versioned libraries only seem useful for libraries that one would need to link to when writing a plugin. We can tell libtool to not create the versioned libraries by adding the "-avoid-version" option to LDFLAGS.
(In reply to comment #12) > We can tell libtool to not create the versioned libraries by adding the > "-avoid-version" option to LDFLAGS. Ok. That's a good idea for the plug-ins, or anything loaded via dlopen().