F22 Self Contained Change: Disabled Repositories Support

Stephen Gallagher sgallagh at redhat.com
Mon Mar 16 19:25:42 UTC 2015


On Mon, 2015-03-16 at 13:48 -0400, Mike Pinkerton wrote:
> On 16 Mar 2015, at 12:57, Josh Boyer wrote:
> 
> > > a) This change impacts users, while these COPRs are not useful 
> > > to   them.
> > 
> > There are no COPR repo files that are installed by default today, 
> > which means none of them use this mechanism yet.  Which means 
> > there is literally no change for any user at this time.  As I 
> > said, the Change is informational.
> > 
> > If such repo files are installed by default, it will be at the 
> > discretion of the various Working Groups not the Change proposer.
> 
> Why would an official "product" want to endorse "unofficial" repos?
> 
> If the working group deems the software to be that useful, wouldn't  
> it be better to bring its packaging up to the quality of the   
> "official" Fedora repo, and make it more easily discoverable by all  
> Fedora users, regardless of whether they choose to use that 
> "product"   or a spin or a "non-product" install of Fedora?
> 
> Just asking what the thinking is here ...
> 


One representative example would be software that is extremely useful 
to a large group of people but whose packaging is a nightmare. For 
example, a great many people enjoy the Chromium repository in COPR. 
Due to Google's upstream practices, it's basically impossible to get 
it to meet Fedora's packaging policies. However, Google as an upstream 
is at least responsive enough that it can be trusted to close security 
issues in a timely basis. With that in mind, is it worth introducing 
barriers to our users from installing Chromium simply because of 
packaging problems?

I'd say this is a fair case.

Other examples might be preview releases of certain software that are 
not yet stable enough to be in Fedora proper or whose installation 
might be too disruptive during a stable lifecycle. Like for example 
the recent GNOME 3.12 repositories for Fedora 20 users since we had 
the long cycle.
-------------- 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/devel/attachments/20150316/93f8ae76/attachment.sig>


More information about the devel mailing list