On Fri, 21 Nov 2008 10:37:50 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Yes, but the information for RPM is stored in a database - or rather a
>> series of databases - implemented using Berkeley DB (on my system,
>> version 8).
> 
> I guess if all the information you need to make that decision is stored
> in a transactional database, yah, you should be able to do that sort of
> thing. But then you wouldn't need a read-only version.
> 
> The problem with ACID is too many people stop too soon, thinking (for
> example) that "Consistent" means if the internal structure of the
> database storage isn't screwed up means that the database is consistent.
> 
> If you upgrade GCC from 2.3 to 2.4, and the /usr/bin/gcc file gets
> rewritten and then you crash out before committing the package manager,
> or you have permissions to write to libgcc and overwrite it but fail to
> upgrade /usr/bin/gcc properly, you have an inconsistency.

Yeah, and that sort of thing can happen - though the filesystem layer (on 
top of the actual filesystem at the kernel level - not sure what it's 
specifically called, probably some sort of abstraction layer) deals in 
inodes rather than files.  It's entirely possible to nuke a file that's 
open, along with its parent hierarchy; did that by mistake a few weeks 
ago when running pdfcrack before Eero suggested an alternative approach 
to my issue.  I even replaced the deleted directory with a second 
extracted copy of the source archive and a second copy of the PDF in 
question - but looking at the kernel level, the inodes are different.

> 
> Out of curiousity, how do the package managers work when the packages
> are distributed over the network? If /usr/bin is a NFS mount, for
> example, does package management still work? Or are you back to
> tiptoeing around trying to figure out every file a package will touch?
> Can clients upgrade things, or do you have to try to lock it down at the
> NFS server?

You know, I've never actually looked into that - I know in my Unix 
experience that mounting a remote /var partition wasn't uncommon, 
particularly with diskless workstations (obviously).  I may have to ask 
that question of some of the internal development folks.

Jim

Post a reply to this message