All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] host-libsemanage build failure
Date: Thu, 18 Jan 2018 11:19:24 +0100	[thread overview]
Message-ID: <20180118111924.2a2bfdd9@windsurf.lan> (raw)
In-Reply-To: <20180118101016.GA11479@gmail.com>

Hello,

+Buildroot mailing list in Cc.

On Thu, 18 Jan 2018 11:10:16 +0100, Marcus Folkesson wrote:

> I'm looking at this build, but I'm unable to reproduce it.
> Has this been a problem for a while or is it new? Is it possible to see
> all build results for a certain package?

Yes:

  http://autobuild.buildroot.net/?reason=<package-version>

so:

  http://autobuild.buildroot.net/?reason=host-libsemanage-2.7

So it is the first time that this happens.

> However, I discovered another problem.
> libsemanage is installing configuration files to $(DESTDIR)/etc/, what
> is the best practice to handle these type of installations? I guess the
> SELinux guys do not want to have it installed to
> $(DESTDIR)$(PREFIX)/etc.
> This must have been a problem for a while, it does not seems to be
> related to my patch (same error even if I revert it).

Autotools typically has a separate sysconfdir option, which is not
subject to prefix:

                --prefix=/usr \
                --exec-prefix=/usr \
                --sysconfdir=/etc \

> Is it a big no-no to use DESTDIR=$(HOST_DIR) in the installation stage?
> I know you told me to omit DESTDIR and instead use PREFIX=$(HOST_DIR)
> during host installation.

What is the problem with using the standard semantic?
DESTDIR=$(HOST_DIR) PREFIX=$(HOST_DIR) is not correct because files
would be installed in $(HOST_DIR)/$(HOST_DIR). Just DESTDIR=$(HOST_DIR)
PREFIX=/usr is not correct, because that means the program/library
expects to be executed from /usr.

> When talking about SELinux.. I saw that we have more packages that is
> part of the SELinux project that I should fix:
> - semodule-utils
> - restorecond
> - checkpolicy
> - policycoreutils

Right. Though perhaps we should wait for upstream's feedback. I'm a bit
unsure of what will be upstream's reaction to those patches, so perhaps
wait for feedback before fixing all the remaining packages ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

           reply	other threads:[~2018-01-18 10:19 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20180118101016.GA11479@gmail.com>]

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=20180118111924.2a2bfdd9@windsurf.lan \
    --to=thomas.petazzoni@free-electrons.com \
    --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.