Re: Hamm Beta: Delay #1
"Carl R. Witty" <cwitty@newtonlabs.com> writes:
> I'm afraid that the cvs-pcl dependency on emacsen-common instead of
> emacsen is a bit of a red herring. The problem still occurs even if
> there are other emacsen installed.
Yep.
> However, I believe I do have a simple solution. I'll present the
> solution first, followed by an analysis of the problem, followed by
> further discussion of the solution.
Ok, right off the top, I appreciate the time you've spent thinking
about this. It's somewhat tricky and it helps to have some others (so
far mostly, but not entirely, Manoj :> to bounce things off of). It's
also kind of a PITA to understand fully so I can't blame anyone who
doesn't want to dive in.
Anyway, your solution does address most of the issues, but if you
ignore the difficulty of using tsort over sorting alphabetically, I
think we're better off using tsort. The main question (which I
haven't investigated yet) is can you call dpkg (or use dpkg-perl) from
*within* a dpkg run. Specifically, can you get the necessary
"Depends:" information? If not, then we'll have to keep parallel
information in /usr/lib/emacsen-common/dependencies/<package>.
However, this isn't much worse than using the numbering strategy.
I've got an alternate (unfortunately more complex) solution that I've
been mulling over for a day or so. I'd love it if I could get some
people to see if they can punch holes in it. I think, that it might
solve *all* the outstanding problems, and will also eliminate a huge
number of pointless re-installs.
This proposal also addresses another issue that Manoj and I have been
discussing, "soft-dependencies". We've been contemplating the fact
that there are some add-on packages (like vm and bbdb) where one
shouldn't *depend* on the other in the dpkg sense, but if both *are*
installed, then one can configure itself to take advantage of the
other. I'll save talking about this for last since talking about it
with the rest of the proposal would probably hopelessly confuse
things.
On with the plan...
First, let's presume that we *can* get to the package dependency
information during an install. If we can't it'll be a little messier,
but not substantially different from the following:
To begin with, we'll mandate that every add-on package contain a file
/usr/lib/emacsen-common/packages/build-level/<package-name>
This would contain (for now) a single integer which would represent
the "build level" of the add-on package. Specifically, this integer
would be used by emacsen-common to detect when it needs to re-run the
package's install script.
It would be the responsibility of the package maintainer to bump this
integer whenever anything changed in the package that required a
re-run of the install script. Many things like just modifying the
changelog, control file, etc. wouldn't require a re-"install", but a
new upstream release probably would (though might not).
Emacsen-common's behavior would be modified so that it keeps a record
of the last "build-level" for each add-on package all the relevant
/var/lib/emacsen-common/build-stamps/<flavor>/<package-name>
directories, and emacsen-common would no longer *always* run the
remove script on an upgrade. It would only run the remove script
during actual an dpkg --remove or --purge, or before any (re)run of
the install script.
Given this infrastructure, the package install/remove procedures would
work as follows.
During dpkg installs/removes emacsen-common would use dpkg
"Dependencies:" to order calls to the add-on install and remove
scripts. Emacsen-common wouldn't run the remove/install pair for a
given package unless the build-level in the add-on package was
different from the one stored in .../build-stamps/...
Furthermore (and this is the tricky part), emacsen-common would use
the build-stamps, and build-levels, to determine with even finer
resolution when to run what.
(This is stuff I haven't gone through as thoroughly, but I think it
will work. I just don't have the time to work through it *really*
carefully right now, so if you've got some time to consider it, either
to support or refute it, please do...)
The idea is that emacsen-common could use these bits of info to decide
whether or not to run the remove/install at different points. With
the build-stamp/build-level information, it can know *during* a dpkg
run, when a package is going to need to have it's install script run.
Before, there was no way to tell. Now, you just have to check to see
if the build-level is different than the build-stamp for a given
<flavor>. That means that at the very least we can keep it from
running the scripts for both an emacsen flavor install and for each
relevant separate package in a given run.
The only real drawback I can see here (other than the hassle of
getting something this complicated written correctly) is that add-on
(or emacsen) package re-installs, specifically one's to fix local
accidents, might work unexpectedly.
For example, consider that someone has accidentally rm'ed all the elib
.elc files, and to fix it they figure "ok, I'll just re-install elib".
The problem is that since the build-stamp hasn't changed, the add-on
install script won't be re-run, and the .elc files won't get re-built.
I'm willing to live with this, but does anyone else think this is a
fatal problem?
Finally, to support the "soft-dependencies", we could just allow
packages to create files in the following directories:
/usr/lib/emacsen-common/postinst/<packagename>
/usr/lib/emacsen-common/prerm/<packagename>
with the understanding that emacsen-common would run them as scripts
at the right times in alphabetical order. So vm could contain the
following files:
/usr/lib/emacsen-common/postinst/bbdb/50vm
/usr/lib/emacsen-common/prerm/bbdb/50vm
OK, I'll stop for now. Does this make sense at all? Am I of in
left-field? Have I missed anything?
--
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: