FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-11-2010, 11:52 PM
Rahul Sundaram
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/12/2010 06:14 AM, Kevin Kofler wrote:
>
> How is it disruptive? Surely not because I have to rebuild the stuff I am
> developing myself and have to compile very often anyway
>

Just because you are in a position to rebuild stuff when necessary, does
not mean that is convenient for all consumers of a library to do so and
rebuilding and pushing out updates for software outside the repository
is often problematic. Look at real life environments outside the
developer boxes that you live in. If you don't even agree with a basic
principle that breaking ABI should be avoided in updates, we don't
really have much left to discuss.

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 12:22 AM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Rahul Sundaram wrote:
> If you don't even agree with a basic principle that breaking ABI should be
> avoided in updates, we don't really have much left to discuss.

I don't see this as being a "basic principle" at all. For an enterprise
distro like RHEL or CentOS, sure. But not for something like Fedora. What
counts is that all software in Fedora depending on the library gets rebuilt
and pushed at the same time. (That's what grouped updates are for.) We do
not support third-party software.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 12:28 AM
Chris Adams
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Once upon a time, Kevin Kofler <kevin.kofler@chello.at> said:
> I don't see this as being a "basic principle" at all. For an enterprise
> distro like RHEL or CentOS, sure. But not for something like Fedora. What
> counts is that all software in Fedora depending on the library gets rebuilt
> and pushed at the same time. (That's what grouped updates are for.) We do
> not support third-party software.

There's a difference between not supporting third-party software (is
that actually documented somewhere or another Kevin Kofler rule?) and
intentionally breaking it.

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 02:42 AM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Chris Adams wrote:
> There's a difference between not supporting third-party software (is
> that actually documented somewhere or another Kevin Kofler rule?) and
> intentionally breaking it.

There's no policy saying we support it, ergo by default, we don't.

And we don't intentionally break it, we upgrade a library for some good
reason (there's always a good reason why a soname bump gets pushed) and that
happens to break some third-party software we don't and can't know about.
(When we do, e.g. for software in RPM Fusion, we alert the affected
maintainers so they can rebuild their packages.)

For example, Firefox security updates are impossible to do without ABI
breaks in xulrunner.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 02:14 PM
Matthias Clasen
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Fri, 2010-03-12 at 16:07 +0100, Kevin Kofler wrote:

> Fedora CURRENTLY does NOT provide
> any ABI guarantees. There ARE ALREADY updates which change the ABI (you
> recognize them as they are normally grouped with rebuilds of other stuff for
> the bumped ABI). The people who want to change things are the ones who DON'T
> want to allow soname bumps. The only reason the core libraries you use are
> apparently not affected is that those libraries are used by so many packages
> that rebuilding them all would be impractical.

Stop shouting already. Those abi-changing updates are there because YOU
keep pushing them, making the lives of our users hard without any good
justification other than 'my way or the highway'. It is increasingly
becoming clear that no reasonable compromise is possible with you.


Matthias



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 02:35 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Matthias Clasen wrote:
> Stop shouting already. Those abi-changing updates are there because YOU
> keep pushing them, making the lives of our users hard without any good
> justification other than 'my way or the highway'. It is increasingly
> becoming clear that no reasonable compromise is possible with you.

Uh, I am far from the only one who pushes ABI-changing updates. I'm not even
one of the main offenders. The only ABI bump I remember pushing on my own is
aseqmm/drumstick which is under heavy development upstream, is used by
exactly 1 application in Fedora (KMid2) and only 2 or 3 other apps which are
also under heavy development, regularly pick up new versions of drumstick
and even bundle the drumstick they need (so for third-party builds, if the
version in Fedora is not good or stable enough, the bundled version can be
used). The KDE 4.4 update set did include a few ABI bumps (sip 4.10,
kdelibs-experimental, kipi framework in kdegraphics-libs) with associated
rebuilds, but it was not my decision alone to push that update. Please don't
turn this into an ad hominem discussion.

For example, there are many cases of libraries which are basically only used
by one application, at least within our repository. Those routinely get
bumped, and I really don't see why we'd need to stop that.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 02:38 PM
Andrew Haley
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/12/2010 03:14 PM, Kevin Kofler wrote:
> Andrew Haley wrote:
>> It's a disaster if you're relying on a third-party compiled program
>> for your Internet connectivity. Imagine it: one morning you update,
>> then the connection breaks, then you can't get to the Internet to find
>> out how to get things working again.
>
> And why would we want to support that?

Because we don't despise our users. I don't, anyway.

Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 02:41 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Andrew Haley wrote:
> Because we don't despise our users. I don't, anyway.

If we don't despise our users, we shouldn't let them use crap like third-
party connectivity software which isn't even packaged properly. :-)

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 04:19 PM
Andy Green
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/12/10 15:11, Somebody in the thread at some point said:
> Andy Green wrote:
>
>> On 03/12/10 00:45, Somebody in the thread at some point said:
>>
>>> If you are the user, then you should not be compiling software. :-) You
>>> should be using some repository and that repository is responsible for
>>> rebuilding the package.
>>
>> I tend to agree with what you have been writing but this seems wrong.
>>
>> I don't think I'm the only person who is using Fedora as a basis for
>> homegrown apps, if what I want isn't in Fedora (because I am creating it
>> locally) then I certainly will "compile software" as a Fedora user and
>> the case must be considered.
>
> Uh, please read the context of my statement!
>
> I wrote:
>> Huh? I have to compile the stuff I am developing very often anyway.
>> Having to rebuild it once is not going to be the end of the world.
>
> Simo Sorce replied:
>> It is if you are not the developer but the user.
>
> And I replied:
>> If you are the user, then you should not be compiling software. :-)
>
> In this context, if you're writing homegrown apps, you're a "developer", not
> a "user", so the above sentence obviously does not apply. Instead, my
> original point does (you'll be compiling your own software very often
> anyway).

It's a bit of a false dichotomy because I may be developing my stuff and
using someone else's, but I take your point.

-Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 05:19 PM
Toshio Kuratomi
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Fri, Mar 12, 2010 at 08:05:28AM +0000, Terry Barnaby wrote:
> On 12/03/10 03:42, Kevin Kofler wrote:
> > Chris Adams wrote:
> >> There's a difference between not supporting third-party software (is
> >> that actually documented somewhere or another Kevin Kofler rule?) and
> >> intentionally breaking it.
> >
> > There's no policy saying we support it, ergo by default, we don't.
> >
> > And we don't intentionally break it, we upgrade a library for some good
> > reason (there's always a good reason why a soname bump gets pushed) and that
> > happens to break some third-party software we don't and can't know about.
> > (When we do, e.g. for software in RPM Fusion, we alert the affected
> > maintainers so they can rebuild their packages.)
> >
> > For example, Firefox security updates are impossible to do without ABI
> > breaks in xulrunner.
> >
> > Kevin Kofler
> >
> I really strongly disagree that ABI interfaces of the mainly used
> shared libraries could be allowed to change in a "stable" release.
> We develop internal applications that are packaged and go out to a few
> users. We use Fedora primarily as an OS to run applications we need
> rather than an experimentation platform.
> I consider it unacceptable for a system "update" to break the
> ABI for these and any other third-party packages. It would mean failures
> in the field that would require live intervention. This is what
> rawhide is for.
> We would end up by turning off Fedora updating on these systems and in
> effect manage the updates of the system ourselves probably from our own
> repository (our own Fedora spin) or, probably move to a different system.
> I am sure a lot of users, like us, use Fedora for there own purposes and
> develop there own applications for it, but do not maintain them in the
> main Fedora package tree. There's more to Fedora than just the main Fedora
> repository...
>
While I agree with the sentiment that we should try not to break ABI; I do
have to repeat -- Fedora does not require maintaines to backport fixes.
That means that Fedora will break ABI in a release if there is a good
reason to include the new upstream version. (security fix, bugfix that is
deemed worthy, probably not simply for a new feature... but features may
be the reason an ABI breaks when we pull in a new upstream release to fix
a bug and the release includes it.)

If you really find this unacceptable, there's two options:

A) Fedora requires backports for problems that break ABI. Note that this
also means that Fedora may need to have people who create non-upstreamable
patches to software since some upstream fixes may require ABI changes and
we'd need to fix those a different way.

B) You use a different distribution.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org