On Fri, Jan 17, 2014 at 03:45:03PM +0100, Lennart Poettering wrote:
> On Fri, 17.01.14 04:06, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > So there's "binary" compatibility, and "source" compatibility.
> > It would be nice if we could do those changes without
> >
> > a) requiring
On Fri, 17.01.14 13:20, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
>
> On 17/01/14 09:42, Kay Sievers wrote:
> > This year will bring huge flag day compat breaks. We will drop all old
> > D-Bus support, we will require on a bleeding edge kernel, and so on.
>
> Flag-day compatibility
On Fri, 17.01.14 15:45, Lennart Poettering (lenn...@poettering.net) wrote:
> b) The symbols after they have moved must carry a new, correct symbol
>version, it's not an option to just move the library they are defined
>in.
To explain this: we must provide compatibility for processes that
On Fri, 17.01.14 04:06, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> So there's "binary" compatibility, and "source" compatibility.
> It would be nice if we could do those changes without
>
> a) requiring recompilation ("binary")
> b) requiring editing build scripts in dependent packa
On Fri, Jan 17, 2014 at 09:18:49AM +0100, Kay Sievers wrote:
> On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > So there's "binary" compatibility, and "source" compatibility.
> > It would be nice if we could do those changes without
> >
> > a) requiring recompilation ("
On Fri, Jan 17, 2014 at 2:20 PM, Simon McVittie
wrote:
> On 17/01/14 09:42, Kay Sievers wrote:
>> This year will bring huge flag day compat breaks. We will drop all old
>> D-Bus support, we will require on a bleeding edge kernel, and so on.
>
> Flag-day compatibility breaks are a massive pain for
On 17/01/14 09:42, Kay Sievers wrote:
> This year will bring huge flag day compat breaks. We will drop all old
> D-Bus support, we will require on a bleeding edge kernel, and so on.
Flag-day compatibility breaks are a massive pain for distributions. The
more things need to be upgraded in lockstep,
On Fri, Jan 17, 2014 at 10:28 AM, Colin Guthrie wrote:
> As far as I understand things, the goal is to be API compatible in terms
> of function calls, but change the name of the pc files which is an API
> break. Is this a correct summary? (if not then some of my comments below
> don't work :D)
>
>
Hi,
As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)
'Twas brillig, and Kay Sievers at 17/01/14 08:18 did gyre and
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> So there's "binary" compatibility, and "source" compatibility.
> It would be nice if we could do those changes without
>
> a) requiring recompilation ("binary")
> b) requiring editing build scripts in dependent packages ("sourc
10 matches
Mail list logo
