>>>>> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Laurent Martelli <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
