On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote:
> How is the attached patch?
The NEWS file details the migration of the installed scripts from
$(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used
anymore, and custom scripts migrated into $(pkgdatadir)/site/. This
patch will prevent us from forcing this migration, as the old location
will continue to be be used. So it might fix the bug, but it seems bad.
However, this particular example shows how our searching for files may
be insufficient. Presently, there is no way to enforce a separation
between script files and executable files (if such is desired).
The effect of this would be to allow a site to install read-only binary
files that may be used by read-write scripts. In reality, I think ACLs
make this proposition more meaningful, but others can comment on the
concept of privilege separation. Am I taking that idea too far here?
In this light, I would rather see us add a mechanism to find the two
types of file, such that the search paths for each are separated.
Script files can be searched using one list of paths, and binary files
from another. Internally, it seems like we could switch search paths
based on the filename extension being loaded.
At the simplest, this would mean that .cfg and .tcl files use search
paths with $(pkgdatadir), and other files use search paths with
$(pkglibdir). Of course, a simple configuration could list the same
paths in both (e.g. ${HOME}/some/project), but I think this seems like a
better technical solution for the base installation itself.
Does this seem sane? If so, I would like to see you add /// @todo
comments at each of the points of modification, to remind us to remove
these and replace them with a mechanism like the one I described. For
now, your patch may be a necessary hackity-hack-hack-hack. Of course,
this label assumes that others will see this situation the same as I do.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
