On 1/9/15 5:32 AM, Yevhen Kyriukha wrote: > Hello, > > I'd like to know if there is a chance to replace python-smart with DNF > (github.com/rpm-software-management/dnf)? > DNF already has more features than smart and is well supported (smart > is kind of dead project). > I'd like to prepare a set of patches for dnf integration. >
Let me start with I'm not against DNF or any other package management system.. but there were reasons that smart was choosen. If DNF (or another system can meets the requirements, we should strongly consider it.) For smart, it was chosen because it was small and compact. It may not be feature rich, but it was small. (Yes it requires python, but unlike other package management front ends it didn't require C++, Boost, etc.) I don't know the dependency tree for DNF, but if it's small (python and rpm) then it certainly meets that criteria. Smart also had a community that wanted to work with us. (Small, but it was there.) OE uses RPM5 as the default version of rpm. This is because we need support for some of the RPM5 features. RPM5 (and OE) use a 'recommend' as well as requires mechanism. This means the package manager has to be able to deal with the RPM5 API. In the past the YUM developer community was -actively- against working with RPM5. This also means that the package manager has to have the ability to deal with both required and recommended packages. The packages are handled via 'hints' (bits) in the required field as to if they are required or recommended. Recommended items should be sorted the same as required, but if they don't exist shouldn't cause an error. (YUM was never able to do this... likely due to the issue above!) Finally the rest of the OE system would need to be updated to automatically generate the proper package feeds for this system. It's not really difficult, but it has to work in a cross-compile environment. So whatever tools can't embed endian and word size specific fields or problems will be created when the host and target represent different system types. With all of the above set. If you think either DNF, or you will be able to reconcile that.. I'd love to see the patches. Work wise, I think the first step is figure out the dependency tree and see if it's reasonable. (It likely is.) The next step is to get it working with both rpm(4) and rpm5. [including both iterations of the recommended package types] And finally to get the filesystem generation (cross) to work properly with the DNF system. If you have any question, please ask on the list or find me on IRC.. I can help explain some of the history and problems we'd encountered (and fixed) in the past. --Mark -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
