+1

I think we should at least wait until the decision whether this lives in libdnf or in a dnf plugin has been made.

As I read it, the proposal is about introducing a plugin with the functionality. I like this approach. If it eventually makes its way into libdnf, that's fine, but I like the idea of introducing it as a plugin first. This has been done in the past for other parts of dnf, and I think it works well.

I'm not convinced that this is a good default for all use cases, so introducing it as a plugin is nice. I'm curious what the performance metrics will look like (says chart will be posted Jan 2021).

+1

+1

I think we should at least wait until the decision whether this lives in libdnf or in a dnf plugin has been made.

@zbyszek should this be interpreted as a -1 vote?

According to @malmond, it's going to be both a libdnf and a dnf plugin, since we need it for both PackageKit and DNF.

The current implementation of the "glue" is a dnf plugin: https://github.com/facebookincubator/dnf-plugin-cow. I published this to make this publicly testable.

I am pretty confident that I can replace that whole project with a libdnf based plugin, as a PR/patches against libdnf. Once I do, I'll likely remove that github project.

On numbers: I have run some using another plugin for rpm ( https://github.com/malmond77/rpm/tree/measure ). That is only half the picture, and to be blunt I'm not happy with how easy this is to use. My goal is to show some representative numbers for our use case, and for this to be independently verifiable.

I count the vote as (+3,0,-0), since @zbyszek's question was answered almost a week ago. I will proceed with this change proposal as approved.

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z4ROAFJMYYGZZJBIWYNNQZFJ42FT7J5Q/

I have to say I find this acceptance a little strange, at least for the rpm part the proposed changes aren't anywhere near accepted upstream, let alone in a released version which generally is the minimum requirement for rpm changes. Much less be default in F34 whose feature completion deadline is in couple of weeks.

Also, while I've no objections to development of such a feature, I do object with the plans to make it a default. This introduces quite some extra complexity to one of the most critical paths in the operation of the distro, and is filesystem specific at that. This increases the maintenance burden on those of us who will need to deal with any fallout from here on in ongoing basis - installation-related issues are suddenly filesystem specific and much harder to reproduce. Or are the change proposals volunteering to actually watch for rpm bugs in this space from hereafter?

Also, while I've no objections to development of such a feature, I do object with the plans to make it a default

It's not default for any Fedora variant. You have to install the plugin to activate it.

Or are the change proposals volunteering to actually watch for rpm bugs in this space from hereafter?

I would expect that would be the case for this feature, just as it was for @jdieter with zchunk two years ago.

The intent here is to make RPM with CoW an optional feature shipped with Fedora 34. I have no interest in pushing for this to become enabled by default. At some point in the future, we
should have a much better understanding of the impact of enabling the plugin, and whether it is worth having that discussion.

A note on the approach I've taken: I've tried to keep as much of the code for RPM out of the main library as it keeps the risk profile for the changes much smaller. For RPM: 90% of the complexity is in the new cli tool which isn't in the critical path, and in the reflink plugin.

We've been running this code in production for months. I've found and fixed a number of issues. I am particularly interested in taking ownership for bugs and problems in this space long term.

Thanks for the clarifications. Re-reading the initial change announcement now, I see that it's not positioned for default, but somewhere I got a strong impression that it is. Apologies for the unnecessary noise on that then.