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.
