Manoj Srivastava <[EMAIL PROTECTED]> writes:
> May I point out that pkg-order is probqably way overkill for
> this, and you just need to find a way to feed the information to,
> say, tsort? Of course, that makes emacsen-common kinda depend on
> bsdmainutils, but since pkg-order depends on it too that is not so
> bad.
I agree that tsort would be a better choice here.
> So, each emacs add-on package should provide a file like
> /usr/lib/emacsen-common/dependencies/<pkg-name>, which contain lines
> like
>
> <pkg-name> dependnecy-one
> <pkg-name> dependnecy-two
>
> emacsen-common merely concatenates all these files together
> and runs them through tsort, and bingo: depndency order compilations
> are possible.
At first I thought this would be OK, but after some consideration, I
see a substantial problem. Originally I had thought that the add-on
packages would (just like all other packages) use standard
dependencies to handle ordering the package configurations.
Then Manoj pointed out that maybe this was "overkill", and that we
needed to handle this internally (as suggested in the scheme above).
The problem is that although using tsort and internal dependencies
does get the ordering right for the case where someone's installing or
upgrading a flavor of emacs (since it's emacsen-common install script
traverses *all* the add-on package scripts), it doesn't help at all
for cases like this:
dpkg -i cvs-pcl*.deb elib*.deb
Unless dpkg knows something about which configure to run first,
nothing we can do in emacsen-common will affect the ordering, and
unfortunately, "Depends:" is the only mechanism we have to affect
ordering.
I briefly thought about suggesting an enhancement to our package
system to allow you to provide "softer" constraints than Depends,
something like "Config-After:" that would mean, "use these constraints
to order configs, but don't insist they're satisfied". Of course, I
soon realized that that's probably not a good idea.
Manoj has also pointed out that there are a number of cases where
packages need to be "emacsen configured" in a particular order with
respect to each other, but perhaps don't "need" to *depend* on each
other. His particular example was bbdb and vm. Bbdb *can* do some
stuff for vm if it's available, but doesn't have to.
After some consideration, my current take on this puts me roughly back
where I started, but with some better recommendations. This is my
current idea of the policy we should recommend:
Emacsen add-on packages should use the standard package dependency
mechanism to indicate other emacsen packages that they depend on,
specifically, other packages that *must* be installed and configured
for the given package to function. In addition to dpkg's normal use
of this information, emacsen-common will use it to order the runs of
all the add-on package install/remove scripts when a given flavor of
emacs is installed.
If your add-on package doesn't strictly *depend* on another package
(i.e. bbdb and vm), then you have several options (non-exhaustive
list):
1) Add a "Suggests:" or "Recommends:" to the package.
2) Write a small script that configures your package for the
package(s) it depends on, and coordinate with those maintainers
to add calls to that script to their emacsen-common
install/remove scripts.
3) Have the package's code evaluate the situation at runtime (every
invocation) and "do the right thing". For example, some code
could be added to bbdb to check on startup for the existance (or
absense, the package could get removed) of vm and configure
itself accordingly). This could be made quite efficient with
just a little cooperation between the maintainers of the two
packages in question (i.e. just agree on a file that must exist
if the package in question is installed, say /usr/lib/vm/version,
or whatever).
Thoughts.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
