Bug 234893

Created attachment 151466 [details]
configure.ac

Created attachment 151468 [details]
Makefile.am

Created attachment 151469 [details]
Derived or standard files

Files:
Makefile.in aclocal.m4 autogen.sh compile
config.guess config.h.in config.sub
configure depcomp install-sh ltmain.sh
m4/fhs.m4 m4/mozldap.m4 m4/nspr.m4 m4/nss.m4
m4/sasl.m4 m4/svrcore.m4
missing

Looks good!  Some comments - configure.ac:
1) I think the version should be 1.1.0 in configure.ac instead of 1.0
2) I think we only want to define LDAP_DEBUG if we are doing --enable-debug?
3) What is setupdir used for?
4) I think setuplibdir should just be $(libdir) - no subdir
5) setupsbindir should just be $(sbindir) - no subdir
Makefile.am:
6) I think we're going to have to rename setup to be dssetup
7) README.txt and LICENSE.txt usually go in docdir which is usually
/usr/share/doc/packagename-version
8) There is a setup.res file - does setup use ICU?
9) The -lcurses and -ltermcap stuff is platform dependent - we will probably
have to add that to configure.ac to determine which ones to use based on
platform - or better, maybe there is already an autoconf check for them

Is there already a setuputil.pc.in file?  We will need one for programs to find
setuputil - I've added one for adminutil too.

Thank you, Rich!
(In reply to comment #4)
> Looks good!  Some comments - configure.ac:
> 1) I think the version should be 1.1.0 in configure.ac instead of 1.0
Fixed.
> 2) I think we only want to define LDAP_DEBUG if we are doing --enable-debug?
It looks it's not used anywhere.  I removed it.  "-DMCC_DEBUG", as well.
> 3) What is setupdir used for?
Removed it.  :p
> 4) I think setuplibdir should just be $(libdir) - no subdir
Then, do we want to change the name "libinstall.so"?  It looks too generic to
me... (See #6)
> 5) setupsbindir should just be $(sbindir) - no subdir
Same here...  "setup" is also too generic? (See #6)

> Makefile.am:
> 6) I think we're going to have to rename setup to be dssetup
Yes!  I like it.  Is it okay to rename libinstall.so to libdsinstall.so?
> 7) README.txt and LICENSE.txt usually go in docdir which is usually
> /usr/share/doc/packagename-version
Okay.  Let me move it...
> 8) There is a setup.res file - does setup use ICU?
Not likely.  But SetupUtil has a capability to handle the "resource file" by
itself...
[setup.inf]
# All dialog strings can be defined in a resource file.
Resource   =      setup.res
> 9) The -lcurses and -ltermcap stuff is platform dependent - we will probably
> have to add that to configure.ac to determine which ones to use based on
> platform - or better, maybe there is already an autoconf check for them
I'm testing these lines now...
AC_SEARCH_LIBS(socket, socket)
AC_SEARCH_LIBS(gethostbyname, nsl)
AC_SEARCH_LIBS(endwin, [curses Hcurses])
> Is there already a setuputil.pc.in file?  We will need one for programs to find
> setuputil - I've added one for adminutil too.
No, not yet.  Let me add it...

(In reply to comment #5)
> > 6) I think we're going to have to rename setup to be dssetup
> Yes!  I like it.  Is it okay to rename libinstall.so to libdsinstall.so?
Yes.
> > 7) README.txt and LICENSE.txt usually go in docdir which is usually
> > /usr/share/doc/packagename-version
> Okay.  Let me move it...
> > 8) There is a setup.res file - does setup use ICU?
> Not likely.  But SetupUtil has a capability to handle the "resource file" by
> itself...
Hmm - weird.  Maybe it uses the .res suffix but a different format?

> > 9) The -lcurses and -ltermcap stuff is platform dependent - we will probably
> > have to add that to configure.ac to determine which ones to use based on
> > platform - or better, maybe there is already an autoconf check for them
> I'm testing these lines now...
> AC_SEARCH_LIBS(socket, socket)
> AC_SEARCH_LIBS(gethostbyname, nsl)
> AC_SEARCH_LIBS(endwin, [curses Hcurses])
Ok.

Created attachment 151604 [details]
revised configure.ac

Created attachment 151605 [details]
revised Makefile.am

Installed image
$ pwd
/opt/dssetuputil
$ ls -R
.:
include/  lib/	sbin/  share/

./include:
dssetuputil-1.1.0/

./include/dssetuputil-1.1.0:
code.h	  ldapu.h   nsutils.h	setupdefs.h  setupnvpair.h  ux-util.h
dialog.h  misc.h    prodinfo.h	setupinst.h  uninstall.h    version.h
global.h  nsdefs.h  setupapi.h	setupldap.h  utf8.h

./lib:
libdsinstall.a	  libdsinstall.so@    libdsinstall.so.1.0.0*
libdsinstall.la*  libdsinstall.so.1@

./sbin:
dssetup*  dsuninstall*	setup.res  unzip_wrapper.pl*

./share:
doc/  dssetuputil-1.1.0/

./share/doc:
dssetuputil-1.1.0/

./share/doc/dssetuputil-1.1.0:
LICENSE.txt  README.txt

./share/dssetuputil-1.1.0:
setup.inf  silent.inf

I don't think we need the version in the include or the data dir.  And I think
we can leave the package name as "setuputil" for now.  If we get some feedback
from the fedora or other OSS community people, we can change it then.  But leave
the files named dssetup, dsuninstall and libdsinstall.

setup.res should go in the same directory as setup.inf and silent.inf since it
is a data file.

(In reply to comment #9)
> I don't think we need the version in the include or the data dir.  And I think
> we can leave the package name as "setuputil" for now.  If we get some feedback
> from the fedora or other OSS community people, we can change it then.  But leave
> the files named dssetup, dsuninstall and libdsinstall.

Okay.

> setup.res should go in the same directory as setup.inf and silent.inf since it
> is a data file.

Reading the code, the "resource file" (which could be defined in the inf file)
is supposed to be in the same directory as the dssetup binary is located (and
year, it's not an ICU resource file.):
[installer/unix/installer.cc]
    611 Installer::Installer (int argc, char **argv)
    612    :_installMode(Interactive), _installType(Typical),_checkBuildNum(Tru
       e),_keepInstallCache(False),_preInstallOnly(False),_checkDomainName(Tru 
      e)
    613 {
    614    /*
    615     * Set up the Installer
    616     */
    617
    618    _baseDir = InstUtil::dirName(argv[0]);
    [...]
    791    filename = _newSuiteSpot.get("resource");
    792
    793    if (filename)
    794    {
    795       NSString resourceFile;
    796       resourceFile = _baseDir + "/" + filename;
    797       customResource.read(resourceFile);
    798    }

Of course, we can change the spec to something like: if the resource file is
full path, then we don't add _baseDir to the filename...  Do we want to do it?

In order to be FHS compliant, we cannot have the resource file in the same dir
as the dssetup/dsuninstall binary.  But, I think to support old style setup
install (e.g. HPUX) we should first look in the _baseDir as it is doing now.  I
think this code will have to do the following:
If filename is not an absolute path (i.e. doesn't begin with '/') look for it
first in _baseDir, then in PROPERTYDIR (may have to have an AC_DEFINE for this -
see the adminutil diffs).  If filename is an absolute path, just use it directly.

Created attachment 151637 [details]
cvs diff installer/unix/{installer.cc, product.cc}

Thanks for your comments, Rich.

I've added the code to check the resource file location.
While testing the code, I noticed I have to do the same thing for the inf file.

For now, it's assumed to see in the same directory as dssetup.

Created attachment 151638 [details]
revised Makefile.am

The file/directory structure looks like this.
$ ls -R *
include:
setuputil/

include/setuputil:
code.h	  ldapu.h   nsutils.h	setupdefs.h  setupnvpair.h  ux-util.h
dialog.h  misc.h    prodinfo.h	setupinst.h  uninstall.h    version.h
global.h  nsdefs.h  setupapi.h	setupldap.h  utf8.h

lib:
libdsinstall.a	  libdsinstall.so@    libdsinstall.so.1.0.0*
libdsinstall.la*  libdsinstall.so.1@

sbin:
dssetup*  dssetup-bin*	dsuninstall*  dsuninstall-bin*	unzip_wrapper.pl*

share:
doc/  setuputil/

share/doc:
setuputil/

share/doc/setuputil:
LICENSE.txt  README.txt

share/setuputil:
setup.inf  setup.res  silent.inf

1) put setup.inf, setup.res, and silent.inf in %datadir/$PACKAGE_NAME dir
2) introduced wrappers to take care of the library paths.

This (2) brings up an issue.  If LD_LIBRARY_PATH is pre-set, "setup" issues a
warning as follows.  Can we stop this since the path is defined in the wrapper
and under our control?
================================================
Notice: Your LD_LIBRARY_PATH variable is set to:

	/usr/lib/dirsec:/usr/lib/dirsec:/usr/lib/dirsec

Please unset LD_LIBRARY_PATH or verify that the
above setting is correct before continuing with
the installation. An incorrect setting may cause
problems during the installation such as the wrong
copy of a shared library being used.

Continue [n]? y
================================================

(In reply to comment #13)
> Created an attachment (id=151638) [edit]
> revised Makefile.am
> 
> The file/directory structure looks like this.
<snip>
> 1) put setup.inf, setup.res, and silent.inf in %datadir/$PACKAGE_NAME dir
> 2) introduced wrappers to take care of the library paths.

Looks good.

> 
> This (2) brings up an issue.  If LD_LIBRARY_PATH is pre-set, "setup" issues a
> warning as follows.  Can we stop this since the path is defined in the wrapper
> and under our control?
> ================================================
> Notice: Your LD_LIBRARY_PATH variable is set to:
> 
> 	/usr/lib/dirsec:/usr/lib/dirsec:/usr/lib/dirsec
> 
> Please unset LD_LIBRARY_PATH or verify that the
> above setting is correct before continuing with
> the installation. An incorrect setting may cause
> problems during the installation such as the wrong
> copy of a shared library being used.
> 
> Continue [n]? y
> ================================================

Yes.  Please remove that.

Created attachment 151698 [details]
cvs diff installer.cc (removing LD_LIBRARY_PATH notice)

File: installer/unix/installer.cc

"setup" was issuing the notice that LD_LIBRARY_PATH was set and it should be
unset.	This is the bug why the "notice" was introduced:
http://raidzilla.sfbay.redhat.com:2222/show_bug.cgi?id=408242
Setup SDK - 4.5     General	RESOLVED    Beta1:Chrysler:LD_LIBRARY_PATH
causes obscure install failureu

The customer already had iDS 4.x installed on their system, and so in their
shell LD_LIBRARY_PATH had the pathnames of the iDS 4.x server libraries.

Installing iDS 5.0 in a completely different part of the filesystem would fail.

========================================================

Using autotools, we run "dssetup-bin" via the dssetup script, where the
correct, necessary library pathes are chosen to set.  Thus, we have no problem
described in raidzilla 408242.

Created attachment 151722 [details]
Files to be checked in

Files:
  Makefile.am	configure.ac
  aclocal.m4   autogen.sh
  bchecker.ini	 compile
  config.guess	 config.sub
  configure   depcomp
  install-sh
  ltmain.sh   missing
  m4   m4/fhs.m4
  m4/mozldap.m4   m4/nspr.m4
  m4/nss.m4
  m4/sasl.m4   Makefile.in
  setuputil.pc.in 

Additional changes:
1) added setuputil.pc.in
2) added --with-fhs support

Created attachment 151725 [details]
cvs diff buildnu.pl

File: buildnum.pl

Change: buildnum.pl should be able to output the BUILD_NUM string to the
standard out to pass it to make DEFINE.

Created attachment 151728 [details]
cvs commit message

Thank you, Rich, for lots of reviews and suggestions.

Checked in into HEAD.

Obsolete files to be removed:
buildpaths.mk          internal_buildpaths.mk  nscore.mk
components.mk          internal_comp_deps.mk   nsdefs.mk
component_versions.mk  nsconfig.mk             nsperl.mk*
./installer/Makefile
./installer/test/Makefile
./installer/Makefile
./installer/unix/Makefile
./installer/unix/lib/Makefile
./installer/lib/Makefile
fedora-setuputil.spec.tmpl  setuputil.spec.tmpl

There are some more:
$ ls config
common.mn        HP-UX.mk     nfspwd.pl    revdepth-nt.pl     SunOS5.9.mk
config.mk        Linux2.4.mk  nsinstall.c  revdepth.pl        SunOS5.mk
CVS/             Linux2.6.mk  pathsub.c    rules.mk           UNIX.mk
HP-UXB.11.11.mk  Makefile     pathsub.h    SunOS5.8_i86pc.mk  webint.mk
HP-UXB.11.23.mk  nfspwd*      revdepth*    SunOS5.8.mk        WINNT5.0.mk

Yes, please remove the obsolete files.

Created attachment 151793 [details]
setuputil.spec

[How to make RPM packages]
cd <src_root> # where setuputil is checked out
mkdir SPECS SOURCES RPMS BUILD
cp setuputil/setuputil.spec SPECS
ln -s setuputil/ setuputil-1.1.0
tar chjf SOURCES/setuputil-1.1.0.tar.bz2 setuputil-1.1.0/
rpmbuild --define="_topdir `pwd`" --target i386 --bb SPECS/setuputil.spec

[Install/uninstall setuputil]
$ cd RPMS/i386
$ ls
setuputil-1.1.0-1.i386.rpm	      setuputil-devel-1.1.0-1.i386.rpm
setuputil-debuginfo-1.1.0-1.i386.rpm
$ rpm -q setuputil
package setuputil is not installed
$ sudo rpm -i setuputil-1.1.0-1.i386.rpm
$ rpm -ql setuputil
/usr/lib/libdsinstall.so.1
/usr/lib/libdsinstall.so.1.0.0
/usr/sbin/dssetup
/usr/sbin/dssetup-bin
/usr/sbin/dsuninstall
/usr/sbin/dsuninstall-bin
/usr/sbin/unzip_wrapper.pl
/usr/share/doc/setuputil/LICENSE.txt
/usr/share/doc/setuputil/README.txt
/usr/share/setuputil/setup.inf
/usr/share/setuputil/setup.res
/usr/share/setuputil/silent.inf
$ sudo rpm -e setuputil
$ rpm -q setuputil
package setuputil is not installed

Created attachment 151794 [details]
cvs commit message (removing obsolete files)

Comment #21 From Rich Megginson (rmeggins)	 on 2007-04-05 13:03
EST	   
> Yes, please remove the obsolete files.

Thank you, Rich!  Committed the change into HEAD.

SetupUtil is no longer the part of FDS 1.1 nor RHDS 8.0.
Thus, no need to be verified.
Changing the status to NOTABUG.