Bug#516254: closed by Enrico Zini <enrico at debian.org> (Bug#515791: fixed in apt-xapian-index 0.17)

[Enrico Zini]

On Mon, Feb 23, 2009 at 01:32:20AM +0900, Junichi Uekawa wrote:
> At Sat, 21 Feb 2009 15:18:17 +0000,
> Enrico Zini wrote:
> > apt-xapian-index isn't really a daemon: it rebuilds the index and exits.
> But it is ran on the background.
> I don't really want something running on the background for every
> pbuilder invokation if it's not essential.  chroot is going to be
> cleaned after apt-get finishes running.

That's a good point.  How come your pbuilder setup installs
apt-xapian-index?  It's usually pulled in by aptitude, but as a
Recommends, not a Depends.  In theory, buildds and pbuilder chroots
shouldn't install Recommends, or am I mistaken?

I'd be happy to work out a way not to have apt-xapian-index run in cases
like pbuilder.  Is invoke-rc.d the only tool that honours the init
script policy?  Would it be acceptable if apt-xapian-index's postinst
checked with policy-rc.d to see if it should run the reindexing or not?

> On a side note, if it's being invoked twice in a row for basic
> installation, you probably want to do it in triggers.

That is not necessary, if invoked twice in a row, two things can happen:

 1. The first instance is still running: in that case, the second
    instance will just connect to it and report its progress.
 2. The first instance has finished: the second instance detects no
    changes in the data sources since the last indexing and does
    nothing.

> I assume the reason of this running in background is 
> 
> 1. no package requires this data from postinst etc.
> 2. only interactive packages really use this data
> 3. and user can live with database file up to one week old.

Almost:

 1. packages don't usually require this data from postinst, etc.
 2. if a package requires the data, they can just run apt-xapian-index
    in the postinst.  If the indexer has been started earlier, then
    postinst will be faster as it won't have to wait for a full
    reindexing.  However, reindexing takes time, and I cannot think of a
    package that requires the index at postinst time
 3. however, the package manager may want to require the index just
    after installation finishes: in that case, after running the
    installation, the package manager can just run
    update-apt-xapian-index to wait until the indexing ends, and report
    progress in the meantime.
 4. any user can live with the database file up to one week old, but
    some applications (like goplay) won't work without an index.
    These application can of course run apt-xapian-index at startup, but
    since the indexing process could be quite slow, it would be good if
    at the first installation they could find the index at least partly
    built when they start the application.

> I don't think it's essential to have this information created every
> time a chroot is created.  Similar situation to man-db.

That is certainly true.  I don't want to treat update-apt-xapian-index
like a daemon, because it's not: 'stop' and 'restart' would make no
sense, starting it at boot would make no sense.

However, I 100% agree that update-a-x-i must NOT run on chroots and slow
down builds.  Let's find a way to do so.  Here are the options that I
can think of:

 - Study how policy-rc.d works, and query it in postinst to see if I
   should run the update or not
 - What does man-db do to prevent the index update?
 - Disabling the update in postinst via a preseedable debconf
   low-priority question

Let's find the best way.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pbuilder-maint/attachments/20090222/2a8a7ad1/attachment.pgp