Re: [PATCH 2/7] Conffile database handling functions
On Fri, May 06, 2011 at 10:58:46AM -0500, Jonathan Nieder wrote:
> > I think pkg:arch would suffice instead of pkg, right?
>
> Yes, probably. I'm not sure whether arch:all packages are currently
> tied to a specific arch.
I'd think that only one instance of arch:all could be installed, but I
haven't read the details of how we're doing multi-arch so perhaps someone
with better insights could confirm/clarify?
> >> What happens if ..._register_new_conffile is called and the conffile
> >> was already registered?
> >
> > Then I think it just replaces the old version. Looking at the code the
> > tmpfn is opened without O_EXCL and then is juse rename()'d to the dest.
>
> Sounds good (to be idempotent). When upgrading to the "same" version,
> this case would come up for every conffile. What's missing is a way
> to unlink removed conffiles from the db and to deal with error unwind.
I don't recall if there's something to clean up older conffiles, but
agree there should be. With error unwind, I don't think it's a *huge*
problem to leave a half-unpacked version of the conffiles around, since
dpkg won't try to use them utnil the package is fully unpacked. Any
cmdline interface to said conffiles might get a bit confused (or otherwise
have to deal with this type of situation, but it might need to anyway
for the sake of being robust).
> Probably makes sense to use O_TRUNC or unlink stale temporaries so
> they can't cause harm.
Agreed, I'd say O_TRUNC without thinking too hard on it.
> OTOH I was hoping there would be some simple way to detect hash
> collisions when they happen. Will be thinking more about this.
Hash collisions *should* be next to impossible. The collisions would
have to be provided by files from the same version of a single package (or
in Guillem's rework, which removes the version subdirectory, the same
package at any point in time, but I think that's for a seperate discussion).
I'm not sure taht with restrictions on posix/fs compatible filenames we
could even generate such a collision if we wanted to.
That said, I guess to consider the system fully robust we would have to
claim that we could deal with it in the hypothetical sense. And to do
that, I guess we'd need to be able to have a mutated version of the hash
as a mapping for a filename, which would mean we'd need a way of mapping
between the hashes and conffiles bidirectionally. I guess if each
installed pkg/arch/version triplet also had some kind of "manifest"
file, then the hash could be used as the initial name, and in the case
of conflict it could be mutated somehow. It'd ugly-up the implementation
a bit though.
I haven't fully thought this through though, maybe you can come up with
a better approach?
sean
--
Reply to: