[PATCH] Enhance RPM support
Rob Landley
rob at landley.net
Sat Feb 18 00:22:29 UTC 2006
On Friday 17 February 2006 2:32 pm, Andy Green wrote:
> Rob Landley wrote:
> > Identity of the binary was just a "can this go in real quick for 1.1.1"
> > thing. I see that refactoring main() is an important part of adding this
>
> Hi Rob -
>
> I really appreciated the old code, it was very well and tightly written
> and reliably parsed RPMs like it set out to do, and was a great base to
> add to. However the functionality it delivered had no meaning over
> unpacking a tarball or cpio archive: this is why I did not try to
> preserve it from the start. It seemed to me intended to be a start on a
> larger implementation. I assume you only want to preserve it because it
> was already there, not because you think it is actually useful in itself
> as a package management app.
I want to preserve it because it has an existing user base and it's small. (I
don't like to take away the option to do do the small crappy thing rather
than the large elegant thing, no matter how cool the large elegant thing is
cool.)
I'm not worried about implementation, that can change. I just want to make
sure we can .config the old functionality down to the old size somehow.
> It labeled itself as RPM but it was more
> like rpm2cpio with rpm switch semantics, whereas the new code goes quite
> far in giving rpm-like functionality.
Entirely agreed.
Possibly the best thing is to expand rpm2cpio with an --install switch that
gives the old functionality. Dunno. I'll worry about it after 1.1.1...
> So I find myself disagreeing that
> refactoring main() to allow the old methodology is "an important part".
> I should have disagreed at the previous step but I was trying to work
> with your requests.
What would be involved in adding --install capability to rpm2cpio instead
then?
> It would suit me to get the functionality into base busybox but if there
> are problems with doing that then for my uses I am just as happy to
> externally patch instead and its not my loss. The code is all GPL so if
> someone else wants to stitch it in as you require they can go ahead (but
> I doubt I will use the resulting spaghetti in favour of the clean new
> implementation).
>
> Best of luck with rolling out 1.1.1!
>
> -Andy
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list