Re: Debian is not a "main distro"?
Rob Browning <rlb@cs.utexas.edu> writes:
> If I get the time, I'll try to find the message I sent about reducing
> redundant recompiles and see what I think about it now, but don't hold
> your breath, it's a nasty little problem.
Wow, it was right there, higher up in my debian-devel summary buffer.
For those who didn't see it before, here are the relevant bits from
what I said (I never got any feedback on any of this, so I take that
as CarteBlanche to do what I want :>)
Oh, and I'm not sure my "elimiating pointless rebuilds" solution will
work as stated. It depends on whether or not we think that macros
will often be a problem. I suppose that if the package is *always*
re-bytecompiled when a new revision of emacs is released, and whenever
any new versions of any of the packages it depends on are released,
and if the maintainer follows my rules below, then we might be fine.
Problems with macros would then just indicate a missing dependency.
From: Rob Browning <rlb@cs.utexas.edu>
Subject: Emacsen changes: emacsen related maintainers please read.
To: debian-devel@lists.debian.org
Date: 25 Jul 1998 14:53:39 -0500
[...]
* 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? I prefer the latter because the add-on maintainer
can still show something if they *need* to.
* Eliminating some pointless re-builds.
(Updated 1998/10/01)
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 a
much more automatic 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 the install
and remove scripts are told whether they're being called as the result
of an emacs install, remove or an upgrade, or as the result of just
the add-on package being installed or removed, or upgraded. They
might also need to know if they're just being called because a package
they depend on is being upgraded.
Then I'd like to ask that every maintainer store a buildlevel for the
package in /usr/share/<package>/buildlevel. From then on, every time
they make a changes to the package (move to a new upstream version,
etc.) that requires a re-build, they should bump the number stored in
buildlevel.
Then in their emacsen-common install script, during *upgrades*, not
installs, They should check the contents of
/var/lib/<package>/buildstate, and if the value stored in buildstate
is lower than the value in buildlevel, then run the normal install
procedures. After any build, they'd need to copy buildlevel to
buildstate so that they'd know not to re-build again until either
another install or until buildlevel changes.
The code to do something like this would be trivial.
Thoughts?
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: