Re: Hamm Beta: Delay #1
xas.edu> <19980623012503.C23271@lander.es> <877m297ww6.fsf@nevermore.csres.utex
as.edu> <358FB79A.18660662@verisim.com> <874sxc6q1o.fsf@nevermore.csres.utexas.edu>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
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.
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.
The solution is as follows:
In the package cvs-pcl, rename
/usr/lib/emacsen-common/packages/install/cvs-pcl to .../50cvs-pcl,
and change cvs-pcl.postinst to call
/usr/lib/emacsen-common/emacs-package-install 50cvs-pcl
Similarly, in elib, rename
.../install/elib to .../install/35elib, and make the corresponding
change in elib.postinst.
Now I'll try to explain the problem.
I think the reason this problem is so hard to get a grasp on is that
the behavior of the emacs-related postinst's and prerm's depends on
what other packages are installed. (Actually, the behavior of an
add-on postinst depends on what Emacs flavors are configured, and the
behavior of a flavor's postinst depends on what add-on packages are
UNPACKED (as opposed to configured).) This doesn't fit dpkg's view of
the world very well, so people who are used to typical dpkg behavior
have a hard time following what's going on.
In abstract terms, we want all add-on packages to be installed for all
flavors. An add-on's postinst installs that add-on for all currently
configured flavors (in alphabetical order); a flavor's postinst
installs all currently unpacked add-ons for that flavor (in
alphabetical order). (As usual, prerms do the opposite.)
It's not hard to see that, given any sequence of configures of flavors
and add-ons, all the add-ons are installed for all the flavors
(although if both a flavor and an add-on are added in the same dpkg
run, the add-on will be installed for that flavor twice; a minor
inefficiency).
The problem with cvs-pcl is that cvs-pcl must be installed for a given
flavor after elib is installed for that flavor; attempting to install
cvs-pcl for a flavor when elib is not installed for the flavor results
in an error.
So, suppose you start in a state where emacs19, cvs-pcl, and elib are
configured; and you want to install emacs20. When emacs20 is
configured, its postinst will attempt to install cvs-pcl for emacs20,
and then install elib for emacs20 (since cvs-pcl is alphabetically
before emacs20); this will fail. This can't be cured by any number of
calls to dpkg --configure. If you try dpkg --configure elib (or dpkg
--configure cvs-pcl), dpkg will complain because they are already
configured; dpkg --configure emacs20 will just try to install cvs-pcl
and elib for emacs20 in the wrong order again.
Renaming the files in /usr/lib/emacsen-common/packages/install so that
elib's is alphabetically before cvs-pcl's, as suggested above, solves
the problem (although it's not obvious that it does so).
Remember, the failure case is if we try to install cvs-pcl for a
flavor (say emacs20) when we have not yet installed elib for emacs20.
Now, we will try to install cvs-pcl for emacs20 in two circumstances.
First, in emacs20's postinst, we will try to install cvs-pcl for
emacs20 if cvs-pcl has been unpacked. However, if cvs-pcl has been
unpacked, then elib has also been unpacked (since cvs-pcl depends on
elib); so emacs20's postinst will have installed elib for emacs20
before it installs cvs-pcl for emacs20 (since 35elib is alphabetically
before 50cvs-pcl).
Second, in cvs-pcl's postinst, we will try to install cvs-pcl for
emacs20 if emacs20 has been configured. Since cvs-pcl depends on
elib, cvs-pcl won't be configured until elib has been configured. So,
if we try to install cvs-pcl for emacs20 in cvs-pcl's postinst, we
know that both emacs20 and elib have been configured. There are two
possibilities. The first possibility is that elib was configured
before emacs20. In this case, elib was certainly unpacked when
emacs20 was configured, so emacs20's postinst has installed elib for
emacs20. The second possibility is that emacs20 was configured before
elib. In this case, emacs20 was configured when elib was configured,
so elib's postinst has installed elib for emacs20.
There's an obvious drawback to this solution, which is that it isn't
scalable to huge numbers of emacs add-on packages, many of which
depend on each other (since that makes it hard to assign the numeric
prefixes in .../packages/install). I don't think this is likely to
happen; cvs-pcl and elib are the only two elisp packages I can recall
with this kind of dependency (where one must be available to
byte-compile the other). Even if more show up in the future, I think
their number is likely to remain small enough that we can coordinate
centrally (like we have to do for /etc/${FLAVOR}/site-start.d
anyway). In any case, I think my solution is the appropriate solution
for hamm, so Rob doesn't have to figure out how to use tsort or
pkg-order to figure out that elib comes before cvs-pcl.
Carl Witty
cwitty@newtonlabs.com
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: