Replacement for hash_fd

Rob Landley rob at landley.net
Tue Apr 18 17:05:27 UTC 2006


On Tuesday 18 April 2006 2:12 am, Andy Green wrote:
> Rob Landley wrote:
>
> Hi Rob -
>
> >> I also missed hash_fd() on rebasing to 1.1.2, but I quite like the
> >> hash_file() in coreutils/md5_sha1_sum.c as a replacement.  Unfortunately
> >> the enum for its argument type hash_algo_t is defined only at file scope
> >> in that file, and hash_file() itself is declared with static scope.
> >
> > Ah, does this mean I should take my "merge the rpm rewrite" item off my
> > todo list and wait for your next drop instead? :)
>
> Yes the code is still alive and evolving: shortly a fair number of
> remote devices I designed for my customer are going to be relying on it
> to manage their filesystem and perform autoupdates, so it won't be going
> away for me unless my customer does.  I'll send out another patch for it
> this week, but there are a couple of unresolved mechanical questions:
>
>   - What to do about the old RPM implementation.  It is smaller, but I
> don't believe it was actually viable for much since all it could do was
> unpack and query inside the actual RPM package (although I have to pay
> homage to the code itself since it was a fantastic basis for extending
> it) -- It couldn't do rpm -e for example.  The new code is a superset of
> the old functionality I believe.

We've established that CONFIGing down the new rpm code to do what the old one 
did isn't easy.  How about adding a -i option to rpm2cpio so that can do the 
old "stupid install" mode?

It's a user interface change, but it makes a certain amount of sense.  
(Comments?)

>   - I mess with what I think may be generic archive unpack at the moment
> to make being unable to delete a file to replace it nonfatal.  This is
> needed for, eg, a basefilesystem package that manages /dev/pts that can
> be live, and also it seems already extant dirs that are managed by the
> rpm.  I currently do this as a config option that is demanded by the RPM
> config option, but it seems to be a global action for archives.  I can
> qualify the action only to apply for CPIO but maybe there is a larger
> policy issue here

I'm hoping to go through the archive code, understand what it does, and maybe 
clean it up to make this kind of change easier to do.  But it's a big job and 
it's several items down on my todo list.

Glenn's the expert here, but he says he hasn't got the time/drive to do much 
more with the archiver code at present...

> Although there is no depsolving as yet, you can already use the new code
> as the basis of an external autoupdate system.  Basically you can feed
> it a packagename and a version (derived from the package filename is
> fine) and it will tell you if that is older, newer or presently not
> installed without having to have downloaded the actual package.  You are
> then in a position to periodically iterate a wgetted list of available
> packages (from, eg, apache HTML dir listing) in a script and find out
> which packages should be downloaded and installed.  Depsolving can
> eventually work the same external script way by parsing dependency
> errors on stdout from a proposed install or update, isolating the
> dependencies before iteratively downloading and retrying the rpm
> transaction with them.  The combination of minimal functionality in the
> rpm implementation with an external script is lightweight but also
> agnostic about where the update info is coming from and how it is
> formatted.

Cool.

> > That said, we shouldn't hold up moving the current hash_file() to libbb
> > if you can reuse it now.  Feel free to submit a patch for that, and we'll
> > clean it up later if we get the better solution ready by june...
>
> I'll try to address this later in the week along with a new patchset for
> rpm.

Ok.  Granularity is good with something this big.  Small patches we can get 
merged make the remaining lump smaller, and all that...

> -Andy

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list