Third party repos

Stephen Gallagher sgallagh at redhat.com
Thu Feb 26 15:30:51 UTC 2015


On Thu, 2015-02-26 at 14:58 +0000, Richard Hughes wrote:
> On 26 February 2015 at 14:35, Josh Boyer <jwboyer at fedoraproject.org> 
> wrote:
> > > https://fedoraproject.org/wiki/Workstation/3rdPartyApps
> 
> These are the latest designs from Allan that I've implemented in 
> GNOME Software in F22 and rawhide:
> https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version2/wire-third-party-repo-dialogs.png
> 


This may be nitpicking, but what about the cases for things that ARE 
free and open-source, but may still be illegal in certain 
jurisdictions? (Such as patent-encumbered codecs).

> > "The board believes that shipping repository metadata that points 
> > at non-free software is incompatible with Fedora's foundations"
> > and
> > "The board believes that reducing technical barriers to explicit 
> > user choice to install third-party software (non-free or 
> > otherwise) is compatible with Fedora's foundations."
> 
> I had trouble interpreting those two statements, given that the only 
> technical barrier for finding non-free or not-yet-in-fedora software
> *is* repo metadata itself. I assumed the first statement actually
> meant "shipping enabled repository metadata" so we don't show it by 
> default without some other important step.
> 

(The following statement is my interpretation, not the official 
position of the Council):
I think that what this means is that they did not want us shipping 
/etc/yum.repos.d/google-chrome.repo (enabled *or* disabled), but that 
it's acceptable for GNOME Software to make it easier to acquire that 
repo file and enable/disable it.

For example, installing a default MIME-type handler for files ending 
in .repo that allows GNOME Software to be launched and prompt you to 
load it if you click on such a path in a web browser. I think that 
would be in line with both statements.


> > The latter statement led to some of the disabled repo work that 
> > Richard did, IIRC.  It leaves a lot open to interpretation.
> 
> Right, as a simple proposal, would it be acceptable for a package to 
> install something like this into /etc/yum.repos.d:
> 
> [google-chrome]
> name=google-chrome
> baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
> enabled=0
> gpgcheck=1
> repo_gpgcheck=1
> enabled_metadata=1
> gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
> 
> So the only time we'd access that repo is with PackageKit when 
> searching with gnome-software, and we'd only prompt to enable the 
> repo if it matched a search keyword like "chrome", and then did that 
> with a big dialog like the mockups warning about the perils and 
> morality of using nonfree software. Using dnf or yum it would be 
> completely invisible due to the enabled=0 line. This was basically 
> my proposal here: 
> http://blogs.gnome.org/hughsie/2015/01/09/finding-hidden-applications-with-gnome-software/
> which didn't seem too controversial at the time.
> 
> I imagined that we'd ship a fedora-repos-extra package which we 
> could pull onto just the workstation product using comps, but I'm 
> open for ideas.
> 


I'd say that this is probably directly against the intent of the first 
statement above, but it may be worth bringing that to the new Council 
directly. It may have a different result this time around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20150226/e1944a1a/attachment.sig>


More information about the desktop mailing list