Re: I'm sorry to open another can of worms but.. /usr/share/man transition

[Laurent Martelli <martelli@iie.cnam.fr>]

>>>>> "JP" == Jean Pierre LeJacq <jplejacq@quoininc.com> writes:

  JP> On 5 Aug 1999, Chris Waters wrote:

  >> Laurent Martelli <martelli@iie.cnam.fr> writes:
  >> 
  >> > My very personal opinion about all this, is that we need more >
  >> abstraction : packages _should_not_ hardcode installation
  >> paths. I > think that it should be an option that the sysadmin
  >> should be able to > change anytime, without having to rebuild all
  >> packages.
  >> 
  >> I think this is a great idea in concept.  I think implementation
  >> may be a bit tricky, though, and I'd hate to have to rely on this
  >> as a short term solution.  But long term, yes, I would
  >> enthusiastically support such an idea, or some reasonable subset,
  >> if it were well thought out.  Now all we need is a *workable*
  >> proposal or six.  :-)

  JP> I've implemented this idea at build time for the packages I
  JP> maintain to allow support for placing the packages either in the
  JP> standard Debian directory hierarchy or the /opt, /etc/opt,
  JP> /var/opt structure.  This involved: 1) defining the directory
  JP> structure for both Debian and the package; and 2) parameterizing
  JP> the build on the directory structure.  This adds an additional
  JP> layer of abstraction to the build process.

  JP> Providing the parameterization at install time would be
  JP> substantially more difficult.  For example, the wn http server I
  JP> maintain hardcodes several paths into its executables.

I agree that this is more work, but I don't think it is really
difficult.

-- 
Laurent Martelli
martelli@iie.cnam.fr