From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 0/4] Add file capability/xattr support
Date: Thu, 25 Feb 2016 18:00:37 -0300 [thread overview]
Message-ID: <56CF6B75.10604@free-electrons.com> (raw)
In-Reply-To: <20160225215003.5886d69d@free-electrons.com>
On 25/02/16 17:50, Thomas Petazzoni wrote:
> So, if you think that specifying the capabilities or extended
> attributes should be done via a separate data file, then it means we
> will have a new option to specify this data file, and we could
> therefore only bring the additional host-fakeroot dependencies only
> when this option is enabled, no?
Hi.
This is a RFC mostly since it's not complete, although it can be
commited as-is it's not usable directly without tweaking the fakeroot
script (which isn't exposed functionality at the moment).
We can extend makedevs syntax/tool, but i believe it will be terribly
messy for scenarios where multiple XATTRs are desired, more so if we
eventually add ACL support to this.
>> Also not all target filesystems support extended attributes.
>
> And possibly the above option should be made visible only when the
> underlying filesystem supports extended attributes.
>
> What do you think?
>
> Thomas
Well, i was hoping for feedback, let's see other opinions.
Enabling capabilities/xattrs/acls might be an option in target
filesystem where people can then add the respective file(s) describing
them, hence making it optional. If it were in makedevs it could be an
option as well but would pollute things quite a bit.
Might be worth adding tar acl/xattr support as well, rigth now squashfs
and maybe ubifs are the only filesystem targets enabled for this.
Regards.
next prev parent reply other threads:[~2016-02-25 21:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 14:26 [Buildroot] [PATCH v2 0/4] Add file capability/xattr support gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 1/4] attr: add host variant gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 2/4] attr: cleanup pointless indentation gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 3/4] libcap: enable extended attribute support gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 4/4] fakeroot: enable capability support gustavo.zacarias at free-electrons.com
2016-02-25 20:50 ` [Buildroot] [PATCH v2 0/4] Add file capability/xattr support Thomas Petazzoni
2016-02-25 21:00 ` Gustavo Zacarias [this message]
2016-02-25 21:10 ` Thomas Petazzoni
2016-02-25 21:29 ` Gustavo Zacarias
2016-02-25 21:34 ` Thomas Petazzoni
2016-02-25 21:26 ` Thomas Petazzoni
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=56CF6B75.10604@free-electrons.com \
--to=gustavo.zacarias@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox