Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
> On Wed, 15 Apr 2020, Matt Turner wrote: >> This is a CBUILD type dependency, right? Then there is no good way to >> express it in EAPI 7. Still, I think that it should be specified in >> BDEPEND (and maybe RDEPEND in addition). > I'm not sure what CBUILD means. What is that? That's a dependency running on the native build system (as opposed to the system being built). https://projects.gentoo.org/pms/7/pms.html#x1-680008.1 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
On Wed, Apr 15, 2020 at 6:44 AM David Michael wrote: > > On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote: > > At the same time, fix the dependency on sys-libs/libcap by moving it to > > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > > during pkg_postinst() when this eclass is intended to run. > > The BDEPEND was added for https://bugs.gentoo.org/700018 , which is > still needed so the command is in / during sysroot builds, or > installing fails. Maybe deps could be: > > EAPI < 7: RDEPEND > EAPI = 7: RDEPEND + BDEPEND > EAPI > 7: IDEPEND Thanks, yeah. That makes sense.
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
On Wed, Apr 15, 2020 at 1:37 AM Ulrich Mueller wrote: > > > On Wed, 15 Apr 2020, Matt Turner wrote: > > > At the same time, fix the dependency on sys-libs/libcap by moving it to > > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > > during pkg_postinst() when this eclass is intended to run. > > This is a CBUILD type dependency, right? Then there is no good way to > express it in EAPI 7. Still, I think that it should be specified in > BDEPEND (and maybe RDEPEND in addition). I'm not sure what CBUILD means. What is that?
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote: > At the same time, fix the dependency on sys-libs/libcap by moving it to > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > during pkg_postinst() when this eclass is intended to run. The BDEPEND was added for https://bugs.gentoo.org/700018 , which is still needed so the command is in / during sysroot builds, or installing fails. Maybe deps could be: EAPI < 7: RDEPEND EAPI = 7: RDEPEND + BDEPEND EAPI > 7: IDEPEND Thanks. David
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
> On Wed, 15 Apr 2020, Matt Turner wrote: > At the same time, fix the dependency on sys-libs/libcap by moving it to > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > during pkg_postinst() when this eclass is intended to run. This is a CBUILD type dependency, right? Then there is no good way to express it in EAPI 7. Still, I think that it should be specified in BDEPEND (and maybe RDEPEND in addition). Ulrich signature.asc Description: PGP signature
[gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
libcap-ng-0.7.10 changed the output format slightly (in upstream commit
bc1a9c07ebf5 "- Add capng_have_permitted_capabilities function and use
it in filecap"), breaking our usage of it. It's obvious that it's not
supposed to be used programmatically given the awful sed'ing we were
already doing. It doesn't seem like there was a compelling reason why it
was added either (bug #454908), so let's just get rid of it.
At the same time, fix the dependency on sys-libs/libcap by moving it to
RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
during pkg_postinst() when this eclass is intended to run.
Signed-off-by: Matt Turner
---
eclass/fcaps.eclass | 95 +
1 file changed, 27 insertions(+), 68 deletions(-)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 0bb23f8cca7..43a76e253df 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -33,11 +33,8 @@ _FCAPS_ECLASS=1
IUSE="+filecaps"
-# We can't use libcap-ng atm due to #471414.
-case "${EAPI:-0}" in
- [0-6]) DEPEND="filecaps? ( sys-libs/libcap )" ;;
- *) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
-esac
+# Since it is needed in pkg_postinst() it must be in RDEPEND
+RDEPEND="filecaps? ( sys-libs/libcap )"
# @ECLASS-VARIABLE: FILECAPS
# @DEFAULT_UNSET
@@ -134,69 +131,31 @@ fcaps() {
# by people.
chmod ${caps_mode} "${file}" || die
- # Set/verify funcs for sys-libs/libcap.
- _libcap(){ setcap "${caps}" "${file}" ; }
- _libcap_verify() { setcap -v "${caps}" "${file}"
>/dev/null ; }
-
- # Set/verify funcs for sys-libs/libcap-ng.
- # Note: filecap only supports =ep mode.
- # It also expects a different form:
- # setcap cap_foo,cap_bar
- # filecap foo bar
- _libcap_ng() {
- local caps=",${caps%=ep}"
- filecap "${file}" "${caps//,cap_}"
- }
- _libcap_ng_verify() {
- # libcap-ng has a crappy interface
- local rcaps icaps caps=",${caps%=ep}"
- rcaps=$(filecap "${file}" | \
- sed -nr \
- -e "s:^.{${#file}} +::" \
- -e 's:, +:\n:g' \
- -e 2p | \
- LC_ALL=C sort)
- [[ ${PIPESTATUS[0]} -eq 0 ]] || return 1
- icaps=$(echo "${caps//,cap_}" | LC_ALL=C sort)
- [[ ${rcaps} == ${icaps} ]]
- }
-
- local out cmd notfound=0
- for cmd in _libcap _libcap_ng ; do
- if ! out=$(LC_ALL=C ${cmd} 2>&1) ; then
- case ${out} in
- *"command not found"*)
- : $(( ++notfound ))
- continue
- ;;
- # ENOTSUP and EOPNOTSUPP might be the
same value which means
- # strerror() on them is unstable -- we
can get both. #559608
- *"Not supported"*|\
- *"Operation not supported"*)
- local fstype=$(stat -f -c %T
"${file}")
- ewarn "Could not set caps on
'${file}' due to missing filesystem support:"
- ewarn "* enable XATTR support
for '${fstype}' in your kernel (if configurable)"
- ewarn "* mount the fs with the
user_xattr option (if not the default)"
- ewarn "* enable the relevant
FS_SECURITY option (if configurable)"
- break
- ;;
- *)
- eerror "Setting caps '${caps}'
on file '${file}' failed:"
- eerror "${out}"
- die "could not set caps"
- ;;
- esac
- else
- # Sanity check that everything took.
- ${cmd}_verify || die "Checking cap
