* Re: DNF package manager instead of SMART for rpm
2015-01-09 11:32 DNF package manager instead of SMART for rpm Yevhen Kyriukha
@ 2015-01-09 16:34 ` Mark Hatle
0 siblings, 0 replies; 2+ messages in thread
From: Mark Hatle @ 2015-01-09 16:34 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply [flat|nested] 2+ messages in thread