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

[Junichi Uekawa]

At Sun, 22 Feb 2009 17:58:28 +0000,
Enrico Zini wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> 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?

aptitude is depending on apt-xapian-index.

Package: aptitude
Priority: important
Section: admin
Installed-Size: 10044
Maintainer: Daniel Burrows <dburrows at debian.org>
Architecture: amd64
Version: 0.5.1-1
Depends: apt-xapian-index, libapt-pkg-libc6.7-6-4.6, libc6 (>= 2.7-1), libcwidget3, libept0 (>= 0.5.26), libgcc1 (>= 1:4.1.1), libncursesw5 (>= 5.6+20071006-3), libsigc++-2.0-0c2
a (>= 2.0.2), libstdc++6 (>= 4.2.1), libxapian15, zlib1g (>= 1:1.1.4)
Recommends: aptitude-doc-en | aptitude-doc, libparse-debianchangelog-perl
Suggests: tasksel, debtags

> 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?

For pbuillder specific, it's okay to check for policy-rc.d output.

> > 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.

So, you really don't need the data until a client application requests
it.  The first invocation can probably wait, and the invocation afterwards
can wait

Or you can make installation wait for the rebuild of database.
There isn't much point in making it run in background.

If it's a long process, you should take care to make it run in the
background maybe niced.

> > 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.

Well, because you are running the indexing in background, it is
reasonable that someone would want to stop it, and if stopping is
possible, a restart/start.

> 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?

Probably, man-db just rebuilds the index now in triggers.

>  - Disabling the update in postinst via a preseedable debconf
>    low-priority question

Feasible, but that is probably counterintuitive for users, and I need
a hack for apt-xapian-index in pbuilder.

regards,
	junichi
-- 
dancer@{netfort.gr.jp,debian.org}