On Sun, Feb 24, 2013 at 2:37 AM, Ross Burton wrote:
> Hi,
>
> Just brainstorming out loud, but here's a suggestion that might just please
> everyone:
>
> A virtual provider for the init manager, which can be overridden per-image
> (for main / rescue images).
Yes I was thinking about it too but
On Sun, Feb 24, 2013 at 7:04 PM, Ross Burton wrote:
> On Sunday, 24 February 2013 at 14:06, Otavio Salvador wrote:
>> > DISTRO_FEATURES contains the init script *style* that you want: sysvinit
>> > or systemd. These are not mutually exclusive so specifying both will get
>> > you both directly in
Ross Burton
writes:
> the source, so enabling systemd may well lead to libsystemd-* libraries
> sneaking into your rescue image.
for socket activation and sd_notify(), only libsystemd-daemon is required
which is
-rwxr-xr-x1 root root 11644 Feb 25 09:27
/lib/libsystemd-daemon.so
Khem Raj writes:
>> > On the specifics of the do_install_append, you've seen my comments about
>> > how we're not learning from past mistakes with the way the do_install in
>> > the class was written. I note Phil also agreed with them, both of us
>> > remembering some of the horrors we've dealt w
On Sun, Feb 24, 2013 at 11:04 PM, Ross Burton wrote:
>> The size impact it not negligible; specially for initramfs images but
>> what concerns me even more is the upgrade path from previous users of
>> meta-oe systemd.
>
>
> I obviously didn't make myself clear - the size impact is negligible when
On Sun, Feb 24, 2013 at 10:04:42PM +, Ross Burton wrote:
> On Sunday, 24 February 2013 at 14:06, Otavio Salvador wrote:
> > > DISTRO_FEATURES contains the init script *style* that you want: sysvinit
> > > or systemd. These are not mutually exclusive so specifying both will get
> > > you both
On Sunday, 24 February 2013 at 14:06, Otavio Salvador wrote:
> > DISTRO_FEATURES contains the init script *style* that you want: sysvinit or
> > systemd. These are not mutually exclusive so specifying both will get you
> > both directly in packages that support both. I'm still not convinced we
>
On Sun, Feb 24, 2013 at 5:50 AM, Khem Raj wrote:
> On (16/02/13 11:41), Otavio Salvador wrote:
>> On Sat, Feb 16, 2013 at 10:53 AM, Richard Purdie
>> wrote:
>> > On Sat, 2013-02-16 at 08:47 -0200, Otavio Salvador wrote:
>> >> On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
>> >> wrote:
>> >> > O
On Sun, Feb 24, 2013 at 7:37 AM, Ross Burton wrote:
> Hi,
>
> Just brainstorming out loud, but here's a suggestion that might just please
> everyone:
>
> A virtual provider for the init manager, which can be overridden per-image
> (for main / rescue images).
>
> DISTRO_FEATURES contains the init
On Sunday, 24 February 2013 at 10:37, Ross Burton wrote:
> Here's the fun bit - we can't have two builds of udev in the same distro, and
> that's what could happen, so I think we'll need to cut down to one udev
> instead of two.
Ignore this, we can continue to key off the systemd distro feature
Hi,
Just brainstorming out loud, but here's a suggestion that might just please
everyone:
A virtual provider for the init manager, which can be overridden per-image (for
main / rescue images).
DISTRO_FEATURES contains the init script *style* that you want: sysvinit or
systemd. These are not
On (16/02/13 11:41), Otavio Salvador wrote:
> On Sat, Feb 16, 2013 at 10:53 AM, Richard Purdie
> wrote:
> > On Sat, 2013-02-16 at 08:47 -0200, Otavio Salvador wrote:
> >> On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
> >> wrote:
> >> > On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
> >
"Burton, Ross"
writes:
> "With recent systemd packaging change, the rescue image size grow up
> from 5.9 MiB to 27 MiB because systemd dependencies are hardcoded in
> mandatory packages."
>
> This certainly can happen. core-image-minimal-initramfs went from 19M
> up to 35M if you turn on systemd
On Thu, Feb 21, 2013 at 12:35 PM, Burton, Ross wrote:
> Hi,
>
> This thread started sprawling, so I'll do my best to cover all the
> points. This is also mainly an attempt to get more information as to
> how people are using init managers, as it's still not very clear what
> people want beyond "c
Hi,
This thread started sprawling, so I'll do my best to cover all the
points. This is also mainly an attempt to get more information as to
how people are using init managers, as it's still not very clear what
people want beyond "choice".
"With recent systemd packaging change, the rescue image s
On Thu, 2013-02-21 at 08:50 -0300, Otavio Salvador wrote:
> I fully agree; we have many cases where classes workaround system
> issues/limitations to avoid code duplications so I see no reason why
> this needs to be different with systemd.
If you wanted to propose an addition to the class that pur
On Thu, Feb 21, 2013 at 8:34 AM, Enrico Scholz
wrote:
> "Burton, Ross"
> writes:
>
>> more upstream over time will also integrate systemd unit files
>> directly.
>
> When in 5 or 10 years everybody switched to systemd and installs its
> service files by itself, we can mark the relevant code in th
"Burton, Ross"
writes:
> more upstream over time will also integrate systemd unit files
> directly.
When in 5 or 10 years everybody switched to systemd and installs its
service files by itself, we can mark the relevant code in the class as
deprecated and remove it.
But now, the oe-core systemd
On 21 February 2013 10:34, Enrico Scholz
wrote:
> oh... this means khem's "meta-systemd: Append ${PN} to SYSTEMD_SERVICE"
> patch series is incomplete and all the do_install_append() need to get
> yet more complicated
What was originally in meta-systemd, and what is there by simply
adding a d
"Burton, Ross" writes:
>>> But it doesn't need to be as dangerous as binconfig.bbclass, because
>>> we already list .service or .socket files in SYSTEMD_SERVICE so we
>>> can improve that "find" call
>>
>> Why is 'find' required at all? afaik, only files from $SRC_URI are
>> affected. So we can
On 18 February 2013 10:17, Enrico Scholz
wrote:
>> But it doesn't need to be as dangerous as binconfig.bbclass, because
>> we already list .service or .socket files in SYSTEMD_SERVICE so we can
>> improve that "find" call
>
> Why is 'find' required at all? afaik, only files from $SRC_URI are
> af
Martin Jansa
writes:
>> On the specifics of the do_install_append, you've seen my comments
>> about how we're not learning from past mistakes with the way the
>> do_install in the class was written. I note Phil also agreed with
>> them, both of us remembering some of the horrors we've dealt with
On Sat, Feb 16, 2013 at 12:53:07PM +, Richard Purdie wrote:
> On the specifics of the do_install_append, you've seen my comments about
> how we're not learning from past mistakes with the way the do_install in
> the class was written. I note Phil also agreed with them, both of us
> remembering
Richard Purdie writes:
> meta-oe earned a *horrendous* reputation because of the way systemd was
> implemented there.
Can you point me to the corresponding discussion resp. which aspects of
the meta-oe implementation were criticized?
I can image only two problems with splitted -sysv/-systemd pa
Sorry I didn't pipe up earlier but we are still working from denzil so I hadn't
noticed the steady move away from supporting both sysvinit and systemd in a
single distro. We have a similar use case to Otavio where we are hoping to move
to systemd this year, but we'll need to use sysvinit for our
On Sat, Feb 16, 2013 at 5:40 PM, Martin Jansa wrote:
> On Sat, Feb 16, 2013 at 12:34:58PM +, Richard Purdie wrote:
>> On Sat, 2013-02-16 at 12:57 +0100, Enrico Scholz wrote:
>> > Richard Purdie writes:
>> > >> it would be nice when the decision to make the init manager a
>> > >> distribution
On Sat, Feb 16, 2013 at 12:34:58PM +, Richard Purdie wrote:
> On Sat, 2013-02-16 at 12:57 +0100, Enrico Scholz wrote:
> > Richard Purdie writes:
> > >> it would be nice when the decision to make the init manager a
> > >> distribution
> > >> feature will be reverted to the old oe-meta mechanis
On Sat, Feb 16, 2013 at 10:53 AM, Richard Purdie
wrote:
> On Sat, 2013-02-16 at 08:47 -0200, Otavio Salvador wrote:
>> On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
>> wrote:
>> > On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
>> >> it would be nice when the decision to make the init m
On Sat, Feb 16, 2013 at 10:34 AM, Richard Purdie
wrote:
> On Sat, 2013-02-16 at 12:57 +0100, Enrico Scholz wrote:
>> Richard Purdie writes:
>> >> it would be nice when the decision to make the init manager a distribution
>> >> feature will be reverted to the old oe-meta mechanism.
>> >
>> > The t
On Sat, 2013-02-16 at 08:47 -0200, Otavio Salvador wrote:
> On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
> wrote:
> > On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
> >> it would be nice when the decision to make the init manager a distribution
> >> feature will be reverted to the old
On Sat, 2013-02-16 at 12:57 +0100, Enrico Scholz wrote:
> Richard Purdie writes:
> >> it would be nice when the decision to make the init manager a distribution
> >> feature will be reverted to the old oe-meta mechanism.
> >
> > The trouble is that by making it an "image feature", people will
> >
Richard Purdie writes:
>> it would be nice when the decision to make the init manager a distribution
>> feature will be reverted to the old oe-meta mechanism.
>
> The trouble is that by making it an "image feature", people will
> expect *everything* to work properly and to be able to have fully
>
On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
wrote:
> On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
>> it would be nice when the decision to make the init manager a distribution
>> feature will be reverted to the old oe-meta mechanism.
>>
>> Being a distribution feature means, that pa
On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
> it would be nice when the decision to make the init manager a distribution
> feature will be reverted to the old oe-meta mechanism.
>
> Being a distribution feature means, that packages are created in such a
> way that it is impossible to s
On Fri, Feb 15, 2013 at 04:47:37PM -0200, Otavio Salvador wrote:
> On Fri, Feb 15, 2013 at 4:19 PM, Enrico Scholz
> wrote:
> > Hello,
> >
> > it would be nice when the decision to make the init manager a distribution
> > feature will be reverted to the old oe-meta mechanism.
> >
> > Being a distri
On Fri, Feb 15, 2013 at 4:19 PM, Enrico Scholz
wrote:
> Hello,
>
> it would be nice when the decision to make the init manager a distribution
> feature will be reverted to the old oe-meta mechanism.
>
> Being a distribution feature means, that packages are created in such a
> way that it is imposs
Hello,
it would be nice when the decision to make the init manager a distribution
feature will be reverted to the old oe-meta mechanism.
Being a distribution feature means, that packages are created in such a
way that it is impossible to split off unwanted and heavy weighted
functionality at imag
37 matches
Mail list logo
