> 5) The general movement in anaconda is towards libraries. We are > getting rid of app calls everywhere.. so why not here? librpm is > library and the code is pretty straightforward.. > - open RPM > - get header > - read whatever from the header > - get compression > - get me stream of uncompressed data > - feed it to cpio unpacker > - done Of course, there is some tension here. In lots of places we have moved to using libraries if at all possible. At the same time, we're still using programs for things like raid and lvm. Here's how I see it: If there's a library, we should use that. If there's not a library, we should see if we or someone else can write one and use that. If not, we need to decide whether writing our own code is better than just sucking it up and using the command line tool. Both have their advantages and disadvantages. In this case, I think writing our own code has more disadvantages than advantages. With our own code, we're going to be at the mercy of cpio and rpm format changes - and rpm format changes are already in the works (see: thread about rpm-4.8 going until rawhide). It's also simply more code of our own to have to maintain. I see this as something where the underlying tools will change out from under us and will go unnoticed due to lack of testing until the next RHEL point release. We should strongly consider whether there's an existing library to make use of, and if not then consider just running the tools and dealing with it. > Yum API is much worse according to what I have seen. And we still use it. Cute, but I'm sure if you have specific complaints they will be happy to take a look. - Chrid _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
