Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

Stephen Gallagher sgallagh at redhat.com
Mon Mar 31 11:43:03 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
> On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
>> I promised a while ago that I would provide a text version of my
>> talk at DevConf, for people who couldn't make it and because
>> sitting through a video of me standing up there going on and on
>> doesn't really make for good followup discussion.
>> 
>> I posted a link to the first part last week:
>> 
>> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-i-why/>
>>
>>
>> 
and now, Part II:
>> 
>> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/>
>>
>>
>> 
And as I said last week, I will take questions, comments, complaints, in any
>> media including replies here, on the article, on the social
>> media, or at any bar or coffee shop within walking distance of
>> Boston's MBTA.
> 
> So first I'll say these are interesting articles, and I encourage 
> people to read them.
> 
> I work better when I see some examples of what this would mean in 
> practice.  Under Fedora.next, how & where would you see the
> following being packaged?
> 
> - libvirt
> 
> Big, with lots and lots of big dependencies, but for
> virtualization it's pretty much the definition of a core, stable
> API.
> 

libvirt is one of those pieces that we need to settle on its
positioning. At the absolute minimum, the Fedora Server will almost
certainly declare it part of our guaranteed API. Given its
wide-ranging utility, I'd also like to see it as part of the Base
Design (which means that it is assumed to be a guaranteed API
available to all Products).


> - virt-manager
> 
> An application written in Python, and therefore needing to be
> "above" the stacks layer, I think?
> 

As Matthew noted: these are *policy* rings, not packaging. The idea is
that each ring could conceivably carry different policies, such as
applications that are outside this layer being given relaxed rules
(e.g. bundling exceptions in the outer rings could be assumed rather
than FPC-approved, provided that the RPM includes "Provides:
bundled(libfoo)")[1]




> - VLC
> 
> Free software video player, but with a requirement (or at least
> can use if available) proprietary / patented / ugly / semi-legal
> codecs. Currently packaged in RPMFusion for reasons I'm not clear
> on.
> 

I think it's packaged in RPMFusion because it contains an
implementation of a CSS decoder but I could be mistaken.



[1] Note: this is not an approved proposal, but it's one I'm
personally in favor of.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM5VMcACgkQeiVVYja6o6MX9QCeMbkGUNhWr0yMbZvzomJ+bbD8
1M0AnirwkNvoXJbJsbsfq9APN09cq1FO
=ZR40
-----END PGP SIGNATURE-----


More information about the devel mailing list