update-a-x-i should not run under pbuilder and similar systems

[Enrico Zini]

Package: apt-xapian-index
Severity: serious

On Mon, Feb 23, 2009 at 12:02:32PM +0900, Junichi Uekawa wrote:

We drifted a bit away from the original bug report, and I think this
issue deserves its own bug number.

> > 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
[...]
> 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)

Oh, no.  I've opened a bug with aptitude asking if it can be downgraded
to a Recommends (#516719).  I'm happy to have aptitude on my openmoko,
but I certainly don't want to have apt-xapia-index in it.


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

Where can I find instructions on how to query policy-rc.d for this
specific case?

Can it be just a case of:

if [ ! -x /usr/sbin/policy-rc.d ] || /usr/sbin/policy-rc.d apt-xapian-index start
then
	update-apt-xapian-index --quiet &
fi


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

The point is that the rebuild takes time, and a common use case is that
the data is needed by the package manager just after apt-xapian-index is
installed for the first time.  Rebuilding in background means that when
the installation is finished and we're back to the package manager, the
data will be almost readily available, instead of having to look at a
progress bar for a minute or two.


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

You're right here, I had forgot to nice it.  I've fixed that in git.


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

update-apt-xapian-index --stop to stop a running background indexer is
certainly a good idea: I've added it to the todo list (bug#TODO-TO-BE-ASSIGNED).

Restarting it is just a matter of running update-apt-xapian-index again.

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

I don't mind to use triggers, but I understand that they are only run at
the end of the installation, so it would defeat the idea to start it
soon so that at the end of the installation it's almost done.

Or is there a way to start triggers sooner?


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

Indeed.  It could still be useful in other cases, but not for pbuilder.


It seems that the best way so far is to check policy-rc.d.  I've never
used it, nor I found documentation about how to query it, so I inferred
from invoke-rc.d source code.  If you confirm me the code snippet above
on how to query it, I'll be happy to make an upload right away.


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/20090223/fdda3f13/attachment-0001.pgp