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

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

>>>>> "Chris" == Chris Waters <xtifr@dsp.net> writes:

  Chris> 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.

  Chris> I think this is a great idea in concept.  I think
  Chris> implementation may be a bit tricky, though, and I'd hate to
  Chris> have to rely on this as a short term solution.  But long
  Chris> term, yes, I would enthusiastically support such an idea, or
  Chris> some reasonable subset, if it were well thought out.  Now all
  Chris> we need is a *workable* proposal or six.

I'am not a registered developper, so I don't know exactly how thing
works. And I don't have much time to read all the manuals/policies. 
But I guess that workable means more precise. So I'll try to be more 
precise.

I don't know in details how debian packages work, but it looks like
when the package is built, all the files are put in debian/tmp/, and
then this directory is tar-gzipped to create the deb. At first sight,
it looks incompatible with my proposal, but I think that we could
preserve the old way of doing things. We just need to add a new
"control" file (like postinst, prerm, etc) which would associate
keywords to each file. It would look like this :

======
/usr/doc/my_package/README	documentation
/usr/bin/my_package		binary
/etc/my_package.cfg		configuration
======

Instead of using the path of the files, dpkg would use the keywords to
determine where to put the files. In case there's no keyword for a
file, the old way of doing things is used. 

Now I must define a way to compute a directory name from a list of
keywords. In order to allow easy customization of the scheme used to
do this, it should be done in separate program, or in a dll. A falg
could be used to tell dpkg which dll/binary to use. 

A path-name-computation-method is basically a function taking as
arguments the keywords, the package name, and the base-name of the
file. The result is a full path-name. Some simple functions can be
provided, that are easy to configure. For instance, I can think of
keyword->dirname method, that would be configured by a file like this:

=====
documentation	/usr/share/doc/${package_name}/${basename}
admin,binary	/usr/sbin/${basename}
binary		/usr/bin/${basename}
configuration	/etc/${package_name}/${basename}
data,extra	
data		/usr/share/${package_name}
=====

[files tagged with data and extra are not installed]

I'm just noticing that it is hard subdirs under ${package_name} for
instance. Maybe we should allow values to be associated with
keywords. We could therefore have something like "basedir=foo/bar/"

One other problem is that program should be able to find their files
wherever they were installed. I guess it's doable since dpkg already
support installing files in a custom rootdir. 

Then, a list of standards keywords should be published, with their
meanings clearly explained. A good starting point would be :

	documentation
	admin
	configuration
	binary
	data
	extra
	library
	
I hope this is closer to your idea of workable proposal.

-- 
Laurent Martelli
martelli@iie.cnam.fr