Emacsen changes: emacsen related maintainers please read.
First of all, I'd like to announce that I've fixed the problem with
package install/remove script ordering. Emacsen-common now looks at
the dpkg Depends information to decide how to order the script runs.
This keeps you from getting into the nasty situation (a la cvs-pcl and
elib) where one package that depends on another has it's install
script run first. This can leave things foobared and be very hard to
correct. I'll be releasing the new version 1.4.7 shortly. If it
behaves well for others, I think we need to get it into stable-fixed,
or wherever we're putting that sort of thing.
My current feeling for pacakges like vm and bbdb that have "soft"
dependencies is that these should just be handled by cooperation among
the maintainers. If your package could benefit from some
configuration whenever some other package is installed, but doesn't
*depend* on that package, then you should arrange for the maintainer
of that package to make calls to a script you provide (if it exists)
from their install/remove scripts.
There are also a few other issues I'd like to bring up. These are
things I'm either planning or thinking about, and I'd just like to see
if anyone has any strong opinions about them.
* Squelching install/remove message spew.
First of all, I'd like to cut back on the tremendous spew of messages
we currently see from all the add-on packages. This was helpful in
the initial stages, while we were getting things settled, but now it's
just a mess. I'd like to propose we have an emacsen common logfile,
and that all the add-on install/remove scripts redirect their standard
output and standard error to that file (in append mode). Initially,
I'll probably just clobber the log file on each run.
Assuming this is OK, should the redirection be done in
emacsen-common's scripts, or should it be done in each of the add-on
package scripts? Doing the latter has the advantage that if the
add-on maintainer *needs* to show something they still can.
* Eliminating some pointless re-builds.
Next item is working toward decreasing the number of redundant builds.
For example, if I install calc-XXX-1 and then I install calc-XXX-2,
and the only thing that changed was say the package description, then
it's annoying to have to wait through a pointless re-build.
The difficulty is that only the add-on package maintainer can know
when it's necessary to re-build, so I'm thinking about restructuring
things so that the maintainer will have all the info they need to make
the decision. (Another alternative is to make the whole mechanism
part of emacsen-common, but we should only do that if we think we have
a general enough solution).
What I'd like to do is to re-vamp emacsen-common so that it never
calls the remove script except when either a new flavor of emacs is
being installed or upgraded, or when the add-on package is actually
being removed. I'd like to have it so that the install script is
passed an additional argument which indicates whether or not this is
an "upgrade" or an "install" (install would be used both when the
package is initally installed, and when the script is called because a
new version of an emacsen was installed).
Then the rest is up to the package maintainer. For example, if I was
maintaining a package like "calc", I could store, in
/usr/lib/calc/buildlevel, an integer indicating the current "build
level" of the package. Whenever I make any changes to the package
(move to a new upstream version, etc.) that require a re-build, I
would bump the value in buildlevel. Then in my calc emacsen-common
install script, during *upgrades*, not installs, I would check the
contents of another file, /var/lib/calc/buildstate (or whatever), if
it exists. If the value stored in buildstate is lower than the value in
buildlevel, then I know I need to run the normal install procedures.
Afterward, I copy buildlevel to buildstate.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: