'Twas brillig, and Michael Biebl at 16/01/14 18:22 did gyre and gimble:
> 2014/1/16 Kay Sievers :
>> On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl wrote:
>>> 2014/1/16 Lennart Poettering :
>>
Well, it can certainly continue to use and build against the old version
for a while, no?
>>>
>
2014/1/16 Kay Sievers :
> On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl wrote:
>> 2014/1/16 Lennart Poettering :
>
>>> Well, it can certainly continue to use and build against the old version
>>> for a while, no?
>>
>> We'd have to make pre-systemd-209 and systemd-209 packages
>> co-installable (
On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl wrote:
> 2014/1/16 Lennart Poettering :
>> Well, it can certainly continue to use and build against the old version
>> for a while, no?
>
> We'd have to make pre-systemd-209 and systemd-209 packages
> co-installable (different source package names et
2014/1/16 Lennart Poettering :
> On Thu, 16.01.14 18:27, Michael Biebl (mbi...@gmail.com) wrote:
>
>>
>> 2014/1/16 Lennart Poettering :
>> > On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote:
>> >
>> >>
>> >> 2014/1/16 Zbigniew Jędrzejewski-Szmek :
>> >> > I am also a bit worried about
On Thu, 16.01.14 17:19, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
>
> On 16/01/14 15:41, Lennart Poettering wrote:
> > There are some exceptions to this though. For example, I am unsure about
> > libsystemd-daemon: it's relatively easy to maintain this in its own lib,
> > sicne so fa
2014/1/16 Lennart Poettering :
> On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote:
>
>>
>> 2014/1/16 Zbigniew Jędrzejewski-Szmek :
>> > I am also a bit worried about so-bumps: currently we have very nice
>> > backwards
>> > compatibility, without any API removals. -daemon, -id128, -j
On Thu, 16.01.14 18:27, Michael Biebl (mbi...@gmail.com) wrote:
>
> 2014/1/16 Lennart Poettering :
> > On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote:
> >
> >>
> >> 2014/1/16 Zbigniew Jędrzejewski-Szmek :
> >> > I am also a bit worried about so-bumps: currently we have very nice
On 16/01/14 15:41, Lennart Poettering wrote:
> There are some exceptions to this though. For example, I am unsure about
> libsystemd-daemon: it's relatively easy to maintain this in its own lib,
> sicne so far it actually doesn't use any of the shared code, because
> its' embeddable. But then agaiu
On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote:
>
> 2014/1/16 Zbigniew Jędrzejewski-Szmek :
> > I am also a bit worried about so-bumps: currently we have very nice
> > backwards
> > compatibility, without any API removals. -daemon, -id128, -journal, -login
> > are all still .so.0
On Thu, 16.01.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > There are some exceptions to this though. For example, I am unsure about
> > libsystemd-daemon: it's relatively easy to maintain this in its own lib,
> > sicne so far it actually doesn't use any of the shared code,
On Thu, 16.01.14 17:31, Michael Biebl (mbi...@gmail.com) wrote:
> 2014/1/16 Lennart Poettering :
> > So I am pretty sure libsystemd-id128, libsystemd-login,
> > libsystemd-journal should just end up in a single libsystemd.so together
> > with the event loop, the bus, the asyncns stuff and more. Al
2014/1/16 Zbigniew Jędrzejewski-Szmek :
> I am also a bit worried about so-bumps: currently we have very nice backwards
> compatibility, without any API removals. -daemon, -id128, -journal, -login
> are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
> keep this way, among ot
2014/1/16 Lennart Poettering :
> So I am pretty sure libsystemd-id128, libsystemd-login,
> libsystemd-journal should just end up in a single libsystemd.so together
> with the event loop, the bus, the asyncns stuff and more. All this
> functinality requires each other, and should nto pull in its own
On Thu, Jan 16, 2014 at 5:31 PM, Michael Biebl wrote:
> 2014/1/16 Lennart Poettering :
>> So I am pretty sure libsystemd-id128, libsystemd-login,
>> libsystemd-journal should just end up in a single libsystemd.so together
>> with the event loop, the bus, the asyncns stuff and more. All this
>> fun
On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote:
> On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > Eeeh, why? This new name suggests that this libary is for systemd
> > functionality. But so far it is a generic. Also, we have
> > libsystemd-d
On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> Eeeh, why? This new name suggests that this libary is for systemd
> functionality. But so far it is a generic. Also, we have
> libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
> I'd much prefer
On Tue, Jan 14, 2014 at 5:58 AM, Zbigniew Jędrzejewski-Szmek
wrote:
>> commit c813ca40c859ff8abc8bc6aabc3f1e896623eb67
>> Author: Tom Gundersen
>> Date: Mon Jan 13 19:12:16 2014 +0100
>>
>> libsystemd-dhcp: merge into libsystemd
> OK.
Hmm, maybe DHCP should stay as a separate lib? We shou
On Mon, Jan 13, 2014 at 10:58 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 13, 2014 at 12:10:20PM -0800, Tom Gundersen wrote:
>> commit 5681d7fb8be37771c152d21ea6e95597d664e3f1
>> Author: Tom Gundersen
>> Date: Mon Jan 13 21:03:28 2014 +0100
>>
>> libsystemd-dns: merge into libsyste
On Tue, Jan 14, 2014 at 5:58 AM, Zbigniew Jędrzejewski-Szmek
>> libsystemd-bus: rename to libsystemd
>>
>> Documentation was updated to refer to either 'libsystemd' or 'sd-bus' in
>> place
>> of libsystemd-bus.
> Eeeh, why? This new name suggests that this libary is for systemd
> funct
On Mon, Jan 13, 2014 at 12:10:20PM -0800, Tom Gundersen wrote:
> commit 5681d7fb8be37771c152d21ea6e95597d664e3f1
> Author: Tom Gundersen
> Date: Mon Jan 13 21:03:28 2014 +0100
>
> libsystemd-dns: merge into libsystemd
>
> Also rename sd-dns -> sd-resolv.
Looks good.
> commit 0b5447
20 matches
Mail list logo
