HPML-related thoughts
Here are some thoughts about issues I thought may be worth
investigating in relation to the HPML project:
* Protecting from problems due to simultaneity of an install/upgrade.
Example:
- Package P1 depends on P2
- P2 cannot correctly work before configured [eg. MTA]
What currently happens in Debian is that, usually, both packages are
unpacked, before P2 is configured. P1 entry points (eg. executable
binaries) are already available (`x' bits set) at that time, maybe
causing problems if a user runs P1 at that time.
The only way I'm aware of to prevent this with dpkg v1 is the use of
Predepends fields. This will work on P2 first install, but I'm not
sure of P2 upgrades. Furthermore, Predepends are AFAIK still strongly
discouraged.
I posted quite a long time ago a proposal in an attempt to address
this (with not much success). This proposal suggested to defer
setting execution permissions on binaries from a P2 package until P2
is fully (otherwise) configured. This, however, only handles the case
of executables...
* The "Coding Practice" [2.2] paragraph starts with:
"The success or failure of a project such as this, depends heavily on
the approachability of the source to developers outside of the core
group."
An IMHO interesting, but too rarely used possibility would be to use a
literate programming tool. We have several of them in Debian already
(fweb, cweb, cweb-latex, noweb, maybe others). This is the best way I
know of documenting one's code.
* [current hpml document]
4.2 says: "There are currently 5 planned module interfaces" and only
mentions 4 of them.
[Please CC me - I'm not on debian-devel any more]
--
Yann Dirson <dirson@debian.org>
Reply to: