As many others have expressed, third-party RPMs tend to be done very poorly, Oracle Java is a good bad example. That said, if it's something a user wants to install on their system, that's their prerogative, but it's not part of Fedora and shouldn't be. What we could do is make it easier to install and enable third-party repos, then you actively have to enable them and supposedly you know what you're doing (or are blindly following something you found on Google). For me, I use repos from two providers, Google and RPM Fusion. I think that's pretty common I add the repos in a script I use for new desktop builds. For Google I cat out a repo file and for RPM Fusion I pull down their repo RPM. Being able to dnf install a third party repo would be a cleaner and I wouldn't mind this approach. I would guess there's no legality concern because it's just adding a repo file, but that's for the lawyers to decide.

As far as GUI tools for installing and managing software. I never use them and I think that's common for "power users". That said, I could care less what they do, but expect I can have the same capabilities on the command line, and would expect those capibilities to be available through DNF.

On containerization/sandboxing, I see this as useful from a security perspective, but not for software installation. What I see in the commercial world with SCL is developers don't even try to make their software run natively. Instead they pull a ton of libraries/modules into an SCL environment, package it all in a huge RPM, and then never update the included libraries. I think it would be more useful to work towards some sort of automatic sandboxing and decouple that from software installation.

Avram

On Wed, Jun 15, 2016 at 8:55 AM, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
On Wed, 2016-06-15 at 08:57 +0100, Tom Hughes wrote:
> I have far more worries about third party rpms which can put files 
> anyway, run any scriptlets they like at install time, and generally 
> interfere with the system as a whole.

Yeah, I'm not sure I like this part of the plan either. The goal is to
make it as easy as possible to package software for Fedora, but I'm
thinking that anyone who wants to distribute an RPM repo with metadata
enabled in Fedora ought to be required to follow our packaging
guidelines. That Chrome RPM seems like a weird case... but if Google's
RPM sucks, just imagine what other vendors will do. You can horribly
break the user's system with a bad RPM; there was a recent "dnf
uninstalls sqlite" bug caused by some third-party RPM that bundles
sqlite and also Provides it....

With Flatpak, it's indeed less of an issue. Your Flatpak might suck,
but it can't hurt the system.

Michael