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

Enter Postpone


 316   + 0,9K Jun 10 22:32 Debian Installe cb+myon=de postpone_0.1_amd64.changes is NEW
 320   + 0,4K Jun 11 12:30 Debian Installe cb+myon=de postpone_0.1_amd64.changes ACCEPTED

looks like postpone got fast-tracked in the NEW queue (thanks Joerg!),
so here's what I posted in my blog yesterday again:

--------------- 8< ---------------

I just finished implementing postpone [1], a wrapper that is intended
to take an arbitrary command, fork into the background, wait until
some lockfile is freed, and then run the command. Of course the idea
is that the lockfile is /var/lib/dpkg/lock, and that postpone is used
in maintainer scripts. (Update-menus already does that, and I've
basically grabbed that code and generalized it as a separate program.)

As a test implementation, I modified the post{inst,rm} templates in
the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg
-i texlive-lang-*.deb takes over 4 minutes in the old version, but
only a total of 60s with postpone used (35s for dpkg -i plus 25s for
the background jobs).

A Debian package is currently sitting in NEW, let's hope it will
actually get used in maintainer scripts.

[1] http://www.df7cb.de/projects/postpone/
[2] http://www.df7cb.de/projects/postpone/texlive/

--------------- >8 ---------------

NB, the .diff in [2] is meant as a test implementation and in fact,
I've probably missed some details in the way fmtutil-sys is called.
(And while looks like an NMU, I don't intend to upload it but will
leave the implementation of the maintainer scripts to the experts.)

There's a few other postinst/postrm jobs that could benefit from

* python modules
* emacs
* ldconfig
* install-docs can probably factor out some parts
* update-dictcommon-aspell, aspell-autobuildhash, etc.
* defoma, other font stuff
* scrollkeeper
* anything re-starting some init script (though catching exit code
  won't work anymore)
* maybe even update-menus
* ...

Of course, there are cases where running later is not always
appropriate (ldconfig is a candidate), so this need to be decided on a
case-by-case basis.

For good new, the maintainer scripts are most often generated by
debhelper or some other utility, so there's actually not much to
change to use postpone. (Otherwise, only few packages are affected so
there's not much to gain). And there's the question whether to depend
on postpone or have the maintainer script implement both cases
(postrm scripts might need to do this anyway).

cb@df7cb.de | http://www.df7cb.de/

Attachment: signature.asc
Description: Digital signature

Reply to: