[Rpm-ecosystem] Photon and dnf

Krishna Ganugapati krishnag at vmware.com
Fri Apr 24 05:11:39 UTC 2015


Thanks a ton for the note.  Great to know that you're considering a full C implementation for dnf. That would be an awesome thing to do - we do find a bunch of users who would like this minimal low footprint implementation.

We're happy to look at libhif and if it meets our requirements using it.

One of the key things we're looking to do is build an daemon that calls libtdnf or libhif but provides remotable APIs so that an end user can look at the state of the rpm database and perform operations remotely.
This would allow us to build rich UI (using GTK). We've got a system working with RPC and also looking to build a REST head with authentication.

We'd love to demo this to you guys and get your feedback.  We plan to open source this daemon agent as well. We think this could be a neat addition for remote instrospection of the RPM database.

Perhaps we could collaborate on this as well.

Kind regards,

From: Jan Zelený <jzeleny at redhat.com>
Sent: Wednesday, April 22, 2015 12:18 AM
To: rpm-ecosystem at lists.rpm.org
Cc: Krishna Ganugapati
Subject: Re: [Rpm-ecosystem] Photon and dnf

On 21. 4. 2015 at 20:15:31, Krishna Ganugapati wrote:
> Hello all,
> I wanted to introduce myself - my  name is Krishna Ganugapati and I work on
> the newly released VMware Photon Linux distribution.  Photon is a really
> small  RPM based distro starting at around 70 packages and extensible
> through YUM via yum repositories.
> Even though the focus of  Photon is to function as a container host runtime,
> we felt that the rpm package model is hugely relevant and given that it is
> the established standard, we felt its the only way to go forward.
> For package management on top of rpm, we started with yum and dnf, but one
> of our concerns was that yum and dnf require python and we got a fair
> amount of feedback requesting that we don't have a python system on the
> smallest images.
> So we decided to write a C version of dnf - a  tiny dnf. We also thought it
> would be worthwhile if we could create a C API that other applications
> could write to so we wrote libtdnf. The tdnf utility basically calls the
> libtdnf shared library which itself calls librepo and libhawkey.
> tdnf is pretty small - the whole thing is about 6K lines of C code .  It
> doesn't have all of the extensible Python plugin support that dnf and yum
> do, and in a sense is like the vanilla yum and dnf. We hope to
> systematically implement all of the commands that exist in dnf today.
> We hope to  integrate tdnf with  rpm-ostree as well because we think it is a
> well-thought out model for atomic updates
> We've open sourced it under the LGPL 2.1 license for libtdnf and the GPL 2.0
> license for tdnf. The source can be found here
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vmware_tdnf&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=D9zUgVaf9sn-X5qJArlNUFehpLkA_bwiyfao2YtkkAg&m=wD9snygsJD59KLII2rH3sLMBc8xKJAkZYW08P2FGHJ0&s=2Tod1sg-piKb21nG31RPKLzrqGRHnmEwMPxol6uNFe0&e=
> By the way, Photon will always support the full dnf and yum as standard - we
> want to make sure that tdnf is 100% compatible with dnf and yum.
> We hope the community will view this positively and we would appreciate any
> feedback on how best to engage. tdnf is built with standard tools and
> should be very easily portable on to Fedora, Centos, RHEL and SuSe if there
> is interest.

Hello Krishna,
your timing is impeccable. We discussed the long term plan to move dnf from
Python to C just yesterday. I hope we can use this shared interest to a mutual

One thing I'd like to ask you is to consider using existing libraries even on
the higher level. Your libtdnf sounds quite similar to Richard Hughes's
libhif[1]. One of the things we discussed yesterday was the possibility of dnf
starting to use some of the libhif's functionality. The idea behind it is to
incrementally get rid of multiple implementations of software management
business logic. I think it would make a lot of sense for all three projects
(dnf, tdnf, packagekit) to use one underlying library instead of two or three
different ones.

In any case we appreciate your contributions and I hope we will be
collaborating more closely in the future. Using one library underneath and
thus improving it in the process would be a great start of that collaboration.

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hughsie_libhif&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=D9zUgVaf9sn-X5qJArlNUFehpLkA_bwiyfao2YtkkAg&m=wD9snygsJD59KLII2rH3sLMBc8xKJAkZYW08P2FGHJ0&s=qQsBzBSIRRT5MppoDhY8bcXcfroGjxzj93wZoy9-MoI&e=


More information about the Rpm-ecosystem mailing list