Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 22, 2013 at 5:49 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/22/2013 10:51 AM, Bruno Wolff III wrote:
>> On Mon, Jul 22, 2013 at 09:38:54 -0400, Matthew Miller
>> <mattdm@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Obviously, no-bundled-libs is a crucial part of the packaging
>>> guidelines today. As a sysadmin, I know why it's important. This
>>> is not just a noble goal, but also something that pragmatically
>>> makes systems better. But, it's also keeping us from having
>>> software that people really use in Fedora. Chef and Hadoop are
>>> two big examples. This hurts us more than it helps the world. So,
>>> in some areas, we need a different approach.
>>
>> I'm a bit worried about this. We really want bundled libs to
>> eventually go away (for any particular bundled lib). This seems
>> like it could encourage permanently bundled libs. That is going to
>> make some packages conflicting for a very long time. (And the
>> conflicting packages may not be providing the same service, so that
>> you'd need to run two instances of Fedora to get both sets of
>> services.)
>
> I really agree with Matthew here. The value of unbundling from a
> maintenance perspective is obvious to *us*, but it's seen as limiting
> from the perspective of developers.
>
> Realize that the deployment model of an application developer is very
> different from that of an OS designed. If I am writing a new
> application, I want people to be able to use it. I want that
> application to run basically anywhere with the least amount of
> modification. Writing new features and fixing bugs in my application
> is where I want to spend my time. I'm not going to spend the effort to
> get my application to build on just one particular distribution.

That's all true, but how is it relevant _to Fedora_?  Application
developers are already able to build a "dirty" RPM that bundles dozens
of libraries (and many do).  Perhaps we can, or even need, to make
this easier.

However, the promise of Fedora has never been "any upstream
application is automatically a Fedora RPM"; it's a promise to deliver
Open Source (only) software in a certain way, with a certain standards
and implied promise of an effort to maintain it.

When packaging for Fedora, we unbundle not because it is an aesthetic
preference, but because we believe it is a sound engineering/business
decision that overall saves us maintenance effort and increases
security, even if it means extra work investment during the initial
packaging.  In this, we _differ_ from application developers: we have
dozens or hundreds of applications that use the same library, so the
relative savings gained by unbundling are larger for us.

Perhaps this engineering decision has been incorrect and unbundling is
a net loss for Fedora; however, that's quite unrelated to whether an
application developer would decide to bundle or not.

(And in a perfect world, we would be maintaining API stability in a
way that no developer would even want to bother with the, from their
view, extra and wasted effort on compiling and shipping an extra copy
of an upstream library.  However we're very far from that.)
    Mirek
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux