Tollef Fog Heen <[EMAIL PROTECTED]> writes: > * Martin Uecker > | What bothers me too is the fact that the installer scripts of all > | packages have root permissions during installation. While this might > | be hard to do, in principle I see no good reason why installer > | scripts could not be limited to certain tasks.
> I believe that postinsts need the flexibility shell (or perl or python > or whatever) gives them. If you want to restrict postinsts to only be > able to do a limited set of operations, the quality of packages will > detoriate quite a bit as they are no longer flexible enough to cater for > all packages's needs. I've thought for a while that the best solution to this would be to write an interpreter with a *very simple* language that understands the semantics of Debian maintainer scripts and understands how to do the 50 or 100 most common things that people have to do in maintainer scripts. I think that writing a mini-language with very simple semantics, designed to be very easy to parse and analyze with automated tools, that supports 80% of what people do in maintainer scripts would be fairly straightforward (easily within a Google Summer of Code project). Packages could then have the option. Packagers could depend on that interpreter and use the mini-language, or they could fall back to shell or Perl the way that they do now for the complex cases. You'd probably want to skip config, preinst, and postrm support for the first pass until it's proven to be a good idea and one has built justification for making the package essential, but the long-term goal would be to have that interpreter become essential and have it be the default way of handling maintainer scripts. You can then still bail on packages that do things that are just way too hard and maintain that escape to stronger languages, while still gaining all the benefits of a highly restricted and simple language for the vast majority of packages. I of course have absolutely no time to work on this. :) But it's not something that anyone would need permission or approval to start doing. Anyone could do this right now, propose the language design for peer review here on debian-devel, and upload a package that implements it, and people who want to start experimenting with it could have their packages depend on it. (debhelper support would of course be useful at a fairly early stage, since a fairly substantial percentage of our maintainer scripts are generated at least in part by debhelper.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]