Hi, > 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. The code uses librpm. That IS a library. Only the cpio code isn't and we already agreed to replace it as soon as possible. > > 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. Well how is Yum API different from RPM API when you look at it from the library perspective? The code uses RPM library which understands RPM format. We are not maintaining librpm, where is the problem? The code in anaconda uses public API of RPM library, but somehow, you keep telling me that we will have RPM code in anaconda. We won't and I have said it many times now. Neither the RPM format nor the RPM decompression routines are being included to anaconda. Martin _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
