[OE-core] [PATCH 00/45] Move recipes to use Python 3 whenever possible

[Mark Hatle]

On 5/26/16 8:49 AM, Alexander Kanavin wrote:
> On 05/26/2016 04:39 PM, Mark Hatle wrote:
> 
>> The interchange format of the newer createrepo is very different then the older
>> format the smartpm uses.  Thus they have to be kept in sync.  The new format
>> also does not have the extensions we added for the recommended package syntax.
>>
>> createrepo is very small, and it's not YUM dependent.  It simply reads the
>> metadata (via the rpm interface) and dumps out data in an XML format.. then does
>> a few more things as well.  So porting the existing one forward shouldn't be
>> difficult.  It's just not clear at this point what the best behavior will be to
>> do.. port createrepo forward -- or update smartpm to support the newer format
>> (with appropriate extensions.)
> 
> I still don't understand why introducing yum/dnf as a replacement for 
> smartpm should be avoided at all costs. Like smartpm, it's fully written 
> in Python, so that theoretically should be less painful that building 
> working binaries.

I never said it should be avoided at all costs.  Yum is dead.  So any
discussions would be on DNF.

DNF has many library dependencies that smartpm does not have.  It also has a
larger overhead for other resources.  (But with that said, it also has other
advantages in some cases, like support for DeltaRPM.)

We should investigate DNF, but at present DNF [and the index format] do not
understand the recommended syntax that is used by OE/RPM5.  DNF also has some
issues with the other items that RPM5 has implemented (self-signed packages,
package arch is not 'statically defined', etc.)  Smartpm does not have a problem
with any of these, and is quite small.

Smartpm however does have an issue (maybe) in that it's resolution code is
written in python and likely is much slower then using libsolv [which DNF uses].

So it's not that I'm dismissing DNF, it's that we need to determine what is
necessary to move smartpm forward.  We need to investigate what it will take to
port over DNF... and we need to understand performance impacts (runtime, disk
space, and dependency needs.)

--Mark

> Alex
>