[Rpm-ecosystem] Fedora system upgrades in DNF

Jan Zelený jzeleny at redhat.com
Mon Aug 3 12:19:42 UTC 2015


-- snip --
> > > > Anyway - you're all probably aware that I'm orphaning fedup[1].
> > > > As a
> > > > replacement, I've written dnf-plugin-fedup, which is a
> > > > prototype/proof
> > > > -of-concept that shows how to do system upgrades using systemd's
> > > > Offline Updates[2] support.
> > > > 
> > > > I'd really like to integrate system upgrades into DNF itself -
> > > > or, at
> > > > least, get your opinions about the best way to implement system
> > > > upgrades. What would be the best way to have that discussion?[3]
> > > 
> > > I think that the new rpm-ecosystem list is the best place.
> > > 
> > > FTR, I'm all for integrating Offline Updates into DNF. I believe
> > > that it fits
> > > very well into DNF. But AFAIK, I'm the only one having this opinion
> > > in DNF
> > > team.
> > 
> > Offline updates could be a great feature of DNF but at this point I
> > would like to have
> > it as a separate plugin [4] rather than in DNF itself. Especially if
> > it's just a proof-of-concept.
> 
> Well, to be clear: if this goes into Fedora 22->23, that is
> *production*. It is no longer a proof-of-concept.
> 
> That said, I don't particularly care if it is part of DNF itself, part
> of dnf-plugins-core or a plugin that we (Fedora) simply makes part of
> all of the default installs, as long as the functionality is there on
> everything we ship.

I'd prefer this to be packaged separately. There is a bunch of reasons for 
this, starting with a separate component in bugzilla and ending with 
simplification of administrative processes.

> > I would keep it as a plugin at least for a few Fedora releases and
> > then reconsider merging.
> > We plan to move more code into C and share the main logic with
> > PackageKit - which AFAIK already
> > supports offline updates so we can maybe reuse that code.
> 
> I am really hoping we can reuse as much as possible at the low-level.
> I'm concerned about Workstation/GNOME producing a completely different
> implementation that will require yet more testing. (Besides, the more
> we can implement in PackageKit or the like, the easier it will be for
> the alternative desktops to take advantage of it as well, without being
> forced to resort to the command line).

Agreed, functionality like this should be implemented at low level. However, 
the plan to reuse libhif in dnf is a very long term one.

-- snip --

Thanks
Jan


More information about the Rpm-ecosystem mailing list