From: Richard Purdie <rpurdie@rpsys.net>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] util-linux: disable systemd
Date: Tue, 24 Feb 2015 23:32:03 +0000 [thread overview]
Message-ID: <1424820723.26813.19.camel@rpsys.net> (raw)
In-Reply-To: <1CD26AA6-733E-4DE9-836A-25F0E0FA4C64@gmail.com>
On Tue, 2015-02-24 at 12:48 -0800, Khem Raj wrote:
> > On Feb 24, 2015, at 10:07 AM, Ross Burton <ross.burton@intel.com> wrote:
> >
> > systemd has a build-dependency on util-linux for libmount, and util-linux has an
> > optional build dependency on systemd.
> >
> > The features in util-linux that enabling systemd gives you are:
> > * lslogins can show recent journal entries from the user
> > * uuidd can use socket activation and has a service file
> > * fstrim has a service file
> > * logger can write journal entries
> >
> > These are not worth the overhead of maintaining two util-linux recipes to
> > bootstrap the cycle, so disable systemd support in util-linux.
>
> I feel we are going out of way here since now on systemd based systemd you have to undo this change
> partly via re-introducing service files in some fashion
> how about just building and packaging uuidd and fstrim separately ?
>
> atleast it should be reported to util-linux maintainers.
I'm going to merge this patch and I want to clearly explain why.
With systemd it does seem to pay to be one something approximating the
latest version. I can't do that without doing something about
util-linux.
In history we have no good example of successfully splitting one piece
of source over multiple recipes, apart from perhaps gcc which we'd all
agree is horrible in a variety of ways. Any time we have attempted this,
we've tended to revert or have calls to revert (e.g. avahi).
We're at M3 cutoff and we need to make some decision. If I choose not to
take this, nothing will make 1.8. If I take this, there is the
possibility we can fix up systemd util-linux in some way if it proves to
be that critical.
So whilst I don't think this is perfect and I agree it needs discussion
with the util-linux/systemd folks, I think its perhaps the least worst
option available to me and there are ways we can likely improve things
if/as needed.
Cheers,
Richard
next prev parent reply other threads:[~2015-02-24 23:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 18:07 [PATCH 1/2] util-linux: disable systemd Ross Burton
2015-02-24 18:07 ` [PATCH 2/2] systemd: Upgrade 216 -> 218 Ross Burton
2015-02-24 20:48 ` [PATCH 1/2] util-linux: disable systemd Khem Raj
2015-02-24 20:51 ` Burton, Ross
2015-02-24 22:47 ` Bernhard Reutner-Fischer
2015-02-24 23:32 ` Richard Purdie [this message]
2015-02-25 0:00 ` Khem Raj
2015-02-25 0:28 ` Richard Purdie
2015-02-25 7:07 ` Khem Raj
-- strict thread matches above, loose matches on Subject: below --
2019-01-04 14:12 Paulo Neves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1424820723.26813.19.camel@rpsys.net \
--to=rpurdie@rpsys.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox