[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [debs] Emacs + XFT



Romain Francoise wrote:

Sven Joachim <svenjoac@gmx.de> writes:


If the DOC file is identical for every architecture, yes.


Of course it is, it's just an ASCII text file with some control
characters.

The point is that it is generated (by the `make-docfile' utility) from
a file list, and this file list must always be identical.  This is not
so trivial.  Here is an excerpt from src/Makefile.in that shows how
the DOC file is generated:

,----
| /* We run make-docfile twice because the command line may get too long
|    on some systems.  */
| /* ${SOME_MACHINE_OBJECTS} comes before ${obj} because some files may
|    or may not be included in ${obj}, but they are always included in
|    ${SOME_MACHINE_OBJECTS}.  Since a file is processed when it is mentioned
|    for the first time, this prevents any variation between configurations
|    in the contents of the DOC file.
|    Likewise for ${SOME_MACHINE_LISP}.  */
| ${etc}DOC: ${libsrc}make-docfile${EXEEXT} ${obj} ${shortlisp} ${SOME_MACHINE_LISP}
| 	-rm -f ${etc}DOC
| 	${libsrc}make-docfile -d ${srcdir} ${SOME_MACHINE_OBJECTS} ${obj} > ${etc}DOC
| 	${libsrc}make-docfile -a ${etc}DOC -d ${srcdir} ${SOME_MACHINE_LISP} ${shortlisp}
`----

Thus, it seems that the Emacs maintainers took care that
`make-docfile' always processes the same files in the same order,
independent of the machine's configuration.


You did not mention what I think will be the biggest problem: The
handling of add-on packages in the maintainer scripts.  If you install
multiple binaries of the same emacs flavor, you want to byte-compile
the Elisp files only once.  And if you remove one, but not all of the
binaries of a flavor, you must not purge the byte-compiled files in
the prerm script.  I do not think that emacsen-common can currently
handle these situations. :-(

I did consider this issue and the solution is trivial: the first
"subflavor" package to be installed calls `emacs-install', and the last
package to be removed calls `emacs-remove'... it's a simple matter of
keeping a list of installed subflavors.

The only trick is to ensure that the installed subflavors are all from
the same source package, with versioned conflicts between each subflavor
package.

That would not require any special trick, since the subflavors already
have a versioned dependency on the flavor's -bin-common package.  Or
am I missing something?

But now that I think more about the whole thing, there is another
problem: if /usr/bin/emacs-snapshot becomes an alternative, it'll be set
up from the first subflavor's postinst, and there's a good chance that
it would be too late if an Elisp package's postinst runs before the
subflavor's (it would try to run `emacs-snapshot' and that wouldn't
exist yet).  Hmmm...  Perhaps I should set up this alternative in
preinst instead...

A lot of gory details, but I am confident you will get it right. :-)

Thanks for your fine efforts,

Sven







Reply to: