Gary Benson writes:
Andrew Haley wrote:
> David Walluck writes:
> > I don't know how I feel about the Makefile idea. In any case, it
> > should never require user intervention. What besides sendmail is
> > using this method anyhow? IMO, `make' should be touched by
> > packagers only, certainly not by end users, and not even by system
> > admins.
>
> They won't need to. The question here is how we fix our existing
> scripts so that they don't do unnecessary work. If we do that, then
> they can be called unconditionally. make is the right answer here,
> because it's a tool that already knows how to do the dependency
> analysis that's needed.
All it has to do is read every .db file under /usr/lib/gcj and write
what it finds to a .db file in /var/lib/gcj. Where's the dependency
analysis in that?
We can already do that.
My suggestion was a way to only do that when we know we really have
to. So, if you install a RPM that doesn't add or remove any .db
files, nothing gets rebuilt because make doesn't see any changed
dependencies.
This completely solves the problem of
That aside, having the database rebuilding as an alternative (so
possibly a no-op) would also cause problems. Imagine this:
1. User has GCJ as their JVM.
2. a) User installs some Fedora packages.
b) GCJ database is rebuilt into a consistent state.
3. User switches to some other JVM.
4. a) User installs some more Fedora packages.
b) GCJ database is not rebuilt.
5. User switches to GCJ as their JVM.
The user has ended up with a broken database. His applications will
be slower, and in some (admittedly broken) cases will suddenly start
to fail.
Rather than being an alternative, the rebuild command would need to
rebuild all databases that could be installed on the system. This
could be done by for example having all JVMs drop scripts in some
database, and having 'aot-compile --rebuild' or whatever call them all
in turn.
which was clipped from the mail.
Don't make database rebuilding an alternative. Use make.
Andrew.