All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waldemar Brodkorb <wbx@openadk.org>
To: buildroot@busybox.net
Subject: [Buildroot] pseudo: remaining issues...
Date: Thu, 24 Nov 2016 16:24:30 +0100	[thread overview]
Message-ID: <20161124152430.GG27313@waldemar-brodkorb.de> (raw)
In-Reply-To: <20161123093550.43e574f3@free-electrons.com>

Hi,
Thomas Petazzoni wrote,

> Hello,
> 
> On Tue, 22 Nov 2016 22:25:34 +0100, Yann E. MORIN wrote:
> 
> > Alternatively, we can revert back to using fakeroot for this release, at
> > the expense of breaking (already previously broken) setups with SELinux
> > on the host.
> 
> I am more and more thinking that this is what we should do. Not only
> pseudo still has issues, but even once all issues will be fixed, it is
> a much much more complicated and annoying solution than fakeroot:
> 
>  - It requires additional dependencies (host-sqlite, host-attr)
> 
>  - It requires a complicated setup, with a daemon, that you need to
>    manually start and stop (because the internal pseudo mechanism to
>    start/stop the daemon doesn't work properly)
> 
> So I really believe we should revert to fakeroot, and investigate what
> this SELinux problem is exactly. Looking more at the original bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=1238802, what is the actual
> problem for us? Why do we care about preserving the SELinux labels of
> files within the fakeroot environment? We don't support SELinux, and
> even if we did, most likely the SELinux labels that exist on the host
> machine would not make sense for the target filesystem.
> 
> So is the real problem with fakeroot on Fedora related to SELinux?

If my 2 cent counts, I would revert the pseudo stuff.
It is so complex just shortly before release, just to have some
exotic configurations fixed.

I am also starting some new project with the next release and would
like to have the old fakeroot stuff.

best regards
 Waldemar

  parent reply	other threads:[~2016-11-24 15:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 21:25 [Buildroot] pseudo: remaining issues Yann E. MORIN
2016-11-22 22:16 ` Yann E. MORIN
2016-11-23  5:44   ` Gaël PORTAY
2016-11-22 23:02 ` Arnout Vandecappelle
2016-11-23  6:37   ` Gaël PORTAY
2016-11-23 10:10     ` Arnout Vandecappelle
2016-11-23 18:50       ` Yann E. MORIN
2016-11-23 18:46   ` Yann E. MORIN
2016-11-23  6:29 ` Gaël PORTAY
2016-11-23  8:35 ` Thomas Petazzoni
2016-11-23  8:47   ` Maxime Hadjinlian
2016-11-24 15:24   ` Waldemar Brodkorb [this message]
2016-11-26 23:25   ` Peter Korsgaard

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=20161124152430.GG27313@waldemar-brodkorb.de \
    --to=wbx@openadk.org \
    --cc=buildroot@busybox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.