Bug 211554 - make install needs to use FHS paths
make install needs to use FHS paths
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.0.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 152373 240316
  Show dependency treegraph
 
Reported: 2006-10-19 19:45 EDT by Nathan Kinder
Modified: 2015-12-07 12:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 12:04:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed Fix (9.69 KB, patch)
2006-10-19 19:45 EDT, Nathan Kinder
no flags Details | Diff
requests and questions (2.26 KB, text/plain)
2006-10-19 20:54 EDT, Noriko Hosoi
no flags Details
Proposed Paths (3.19 KB, text/plain)
2006-10-20 15:54 EDT, Nathan Kinder
no flags Details
Revised Makefile.am Diffs (9.86 KB, patch)
2006-10-20 16:55 EDT, Nathan Kinder
no flags Details | Diff
Additional fix for libacl-plugin install issue (1.54 KB, patch)
2006-10-23 14:23 EDT, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Nathan Kinder 2006-10-19 19:45:52 EDT
When running "make isntall", we need to use FHS style paths for the installed
files.  The attached diffs for Makefile.am change the paths to install the
files.  I also added the schema files to the installation as well as infadd
(which wasn't being built before).  Additionally, I renamed the programs to
<program>-bin in preparation for the wrappers that we will create for all of the
programs.

Note:  The Makefile.in diffs have been omitted to make the review easier.
Comment 1 Nathan Kinder 2006-10-19 19:45:52 EDT
Created attachment 138926 [details]
Proposed Fix
Comment 2 Noriko Hosoi 2006-10-19 20:54:32 EDT
Created attachment 138928 [details]
requests and questions

Your current fix looks good (and I'm the witness of the test succeeded :).

Attached is the diffs from the current unpackaged image that I promised.

I wonder we still need to "install" the legacy-schema?	If there is someone who
really need them, they can get them from the source rpm... :>
Comment 3 Rich Megginson 2006-10-20 10:57:38 EDT
> 4)  $ ls usr/share/fedora-ds/ldif
I think we should have two separate LDIF directories - one for the sample LDIF
files which are small and appropriate for a data/examples directory, and one for
db2ldif/ldif2db, which may be really large and contain real data.  Maybe we can
just combine the sample LDIF files with the other example or data files.

> 7)  $ ls usr/share/fedora-ds/plugins/slapi/include
We don't need to package these files anymore - they should already be on the
system when installing the mozldap6-devel package.

> We still install legacy schema???
I think now is the time to get rid of it.  We can always make it available in a
separate package or even just download only, from a link on d.f.r.c.
Comment 4 Nathan Kinder 2006-10-20 15:54:04 EDT
Created attachment 139025 [details]
Proposed Paths

Here's a list of all of the files my current tree is installing, and the paths
it is putting the files in.  It follows Noriko's suggestions for the most part,
with these differences:

- Tools are installed in /usr/bin, not /usr/bin/fedora-ds.

- I'm not installing the sample plugins or the slapi header files.  These will
be in the source rpm and/or a devel package instead.

- I combined the example ldif files and the dbgen data files into a single data
directory.

- I'm not installing the legacy schema, but I went a step further and removed a
bunch of the old Netscape server schema for things like Collabra, Media Server,
Compass, etc.  If we find that I was too aggressive in removing some of these
schema files, we can easily add them back in.  Here's a list of the schema
files that I removed:

       50ns-calendar.ldif
       50ns-compass.ldif
       50ns-delegated-admin.ldif
       50ns-legacy.ldif
       50ns-mail.ldif
       50ns-mcd-browser.ldif
       50ns-mcd-config.ldif
       50ns-mcd-li.ldif
       50ns-mcd-mail.ldif
       50ns-media.ldif
       50ns-mlm.ldif
       50ns-msg.ldif
       50ns-netshare.ldif
       50ns-news.ldif
       50ns-proxy.ldif
       50ns-wcal.ldif
       51ns-calendar.ldif

If all of these changes look fine, I'll attach the Makefile.am diffs for
review.
Comment 5 Noriko Hosoi 2006-10-20 16:08:18 EDT
Pretty close to the image I have...  Found one difference. :)

According to the Rich'es FHS doc:
    http://directory.fedora.redhat.com/wiki/FHS_Packaging#Old_paths_vs._New
Plugins are put in %{_libdir}/fedora-ds; sampe codes are in
%{_datadir}/fedora-ds/plugins:
%{_datadir}/fedora-ds/plugins 	 fedora-ds-devel 	 contains sample code,
makefiles, and headers
%{_libdir}/fedora-ds 	 fedora-ds 	 Server plug-ins - will be able to package new
plug-ins separately

I think these plugins are supposed to go to ./usr/lib/fedora-ds...
    ./usr/share/fedora-ds/plugins:
    libattr-unique-plugin.a
    libattr-unique-plugin.la
    libattr-unique-plugin.so
    libattr-unique-plugin.so.0
    libattr-unique-plugin.so.0.0.0
    [...]
Comment 6 Nathan Kinder 2006-10-20 16:22:14 EDT
I do think the plugins belong under /usr/lib/fedora-ds, but I'd like them to be
in a plugins subdirectory (/usr/lib/fedora-ds/plugins).  /usr/lib/fedora-ds
looks to be a big dumping ground otherwise since that's where we keep ns-slapd,
libslapd, libns-dshttpd, etc.

How does that sound?
Comment 7 Noriko Hosoi 2006-10-20 16:29:12 EDT
(In reply to comment #6)
> I do think the plugins belong under /usr/lib/fedora-ds, but I'd like them to be
> in a plugins subdirectory (/usr/lib/fedora-ds/plugins).  /usr/lib/fedora-ds
> looks to be a big dumping ground otherwise since that's where we keep ns-slapd,
> libslapd, libns-dshttpd, etc.
> 
> How does that sound?

I like your idea.  Current ./usr/lib/fedora-ds looks quite crowded. I think it's
nice to separate plugins from the main server files (as SASL does...)
Comment 8 Rich Megginson 2006-10-20 16:47:41 EDT
Yep.  Sounds good.
Comment 9 Nathan Kinder 2006-10-20 16:55:45 EDT
Created attachment 139031 [details]
Revised Makefile.am Diffs

Here is the revised set of diffs for Makefile.am.  The Makefile.in diffs have
been omitted to make the review easier.
Comment 10 Noriko Hosoi 2006-10-20 17:03:00 EDT
Looks good!
Comment 11 Nathan Kinder 2006-10-20 17:19:16 EDT
Checked into ldapserver (HEAD).  Thanks to Noriko and Rich for their reviews!

Checking in Makefile.am;
/cvs/dirsec/ldapserver/Makefile.am,v  <--  Makefile.am
new revision: 1.5; previous revision: 1.4
done
Checking in Makefile.in;
/cvs/dirsec/ldapserver/Makefile.in,v  <--  Makefile.in
new revision: 1.5; previous revision: 1.4
done
Comment 12 Nathan Kinder 2006-10-23 14:23:36 EDT
Created attachment 139153 [details]
Additional fix for libacl-plugin install issue

Upon further testing, I noticed that libacl-plugin.so was not getting
installed.

This was caused by the failure of a relinking step that libtool does at install
time.  It turns out that "make install" goes through the installation directory
variable names alphabetically when installing files.  This was causing
libacl-plugin (from plugindir) to be installed before libns-dshttpd (from
serverdir).  The relink of libacl-plugin would attempt to link to libns-dshttpd
in it's installed location, which would fail because libns-dshttpd did not
exist there yet.

To fix this, I simply changed the "plugindir" variable name to
"serverplugindir".  This causes the server files to be installed before the
plugins, which allows the relink to succeed.
Comment 13 Rich Megginson 2006-10-23 14:28:19 EDT
Ok.
Comment 14 Nathan Kinder 2006-10-23 14:32:42 EDT
Thanks for the review Rich.  The fix is checked into ldapserver (HEAD).

Checking in Makefile.am;
/cvs/dirsec/ldapserver/Makefile.am,v  <--  Makefile.am
new revision: 1.6; previous revision: 1.5
done
Checking in Makefile.in;
/cvs/dirsec/ldapserver/Makefile.in,v  <--  Makefile.in
new revision: 1.6; previous revision: 1.5
done

Note You need to log in before you can comment on or make changes to this bug.