Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Saturday, July 31, 2021 4:56:34 PM PDT Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
>
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
>
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
>
> Signed-off-by: Sam James
> ---
> metadata/install-qa-check.d/60tmpfiles-paths | 37
> 1 file changed, 37 insertions(+)
> create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
>
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
> b/metadata/install-qa-check.d/60tmpfiles-paths new file mode 100644
> index 0..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit
> the eclass +# Maintainer: Sam James
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
> the eclass +#(needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> + # Check 1
> + # Scan image for files in /etc/tmpfiles.d which is a deprecated
location
> + if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: files installed to the deprecated /etc/
tmpfiles.d
> location" + eqawarn "tmpfiles configuration files must be
installed to
> /usr/lib/tmpfiles.d!" + fi
> +
> + # Check 2
> + # We're now going to check for whether we install files to
> /usr/lib/tmpfiles.d without + # inheriting the eclass (weak catch for
> ebuilds not calling tmpfiles_process in pkg_postinst) +
> + # No need to carry on if we're inheriting the eclass
> + if has tmpfiles ${INHERITED} ; then
> + return
it can actually check if ebuild calls tmpfiles_process, not only inherit.
something like:
local pkg_postinst_body="$(declare -fp pkg_postinst)"
if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
eqawarn "QA Notice: package is installing tmpfiles without calling
eqawarn "tmpfiles_process in pkg_postinst phase"
fi
ofc accounting for edge cases floppym mentioned.
> + fi
> +
> + if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: package is installing tmpfiles without
inheriting
> tmpfiles.eclass!" + eqawarn "Packages must inherit tmpfiles.eclass
then
> call tmpfiles_process in pkg_postinst." + fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh
--
Best regards,
Georgy
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> it can actually check if ebuild calls tmpfiles_process, not only
> inherit.
> something like:
>
> local pkg_postinst_body="$(declare -fp pkg_postinst)"
> if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
> eqawarn "QA Notice: package is installing tmpfiles without
> calling
> eqawarn "tmpfiles_process in pkg_postinst phase"
> fi
>
> ofc accounting for edge cases floppym mentioned.
This is going to cause false positives if tmpfiles_process is called via
another function.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Monday, August 2, 2021 1:30:07 AM PDT Michał Górny wrote:
> On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> > it can actually check if ebuild calls tmpfiles_process, not only
> > inherit.
> > something like:
> >
> > local pkg_postinst_body="$(declare -fp pkg_postinst)"
> > if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
> > eqawarn "QA Notice: package is installing tmpfiles without
> > calling
> > eqawarn "tmpfiles_process in pkg_postinst phase"
> > fi
> >
> > ofc accounting for edge cases floppym mentioned.
>
> This is going to cause false positives if tmpfiles_process is called via
> another function.
ineed, but seems there are no such cases yet.
simple test (via ripgrep): prints all files calling tmpfiles_process at any
point, and checks if any files from the list do not have a string ^pkg_postinst
it may not catch all ofc, because it does not check where call happens or if
it's actually defined, but I think it's good enough.
rg tmpfiles_process --files-with-matches | xargs rg ^pkg_postinst --files-
without-match
1 result, eclass/tmpfiles.eclass, which is fine.
I think adding body checker outweighs possible edge case yet to happen.
ebuilds not calling it already happened, we fixed some.
for example, logrotate was broken out of the box on systemd.
--
Best regards,
Georgy
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-cpp/libxsd-frontend
Last-rite these packages in addition to dev-cpp/libxsd-frontend, seeing that only it needs them and they're abandoned upstream too. dev-cpp/libcutl dev-util/build
Re: [gentoo-dev] About the 'eapi' file in profile directories
> On Sun, 01 Aug 2021, Joshua Kinard wrote: > If EAPI support is really needed in the profiles, it seems like there > has to be a better mechanism to codify it in a more central location > versus scattering ~390 of the things across the base profiles > directory. I have filed https://bugs.gentoo.org/806181 for this. signature.asc Description: PGP signature
Re: [gentoo-dev] About the 'eapi' file in profile directories
On Sun, Aug 1, 2021 at 5:54 PM Ulrich Mueller wrote:
>
> Quoting ciaranm [1]:
>
> | > "EAPIs whose value starts with the string paludis- are reserved for
> | > experimental use by the Paludis package manager."
> |
> | Don't tell anyone, but that's mostly just in there because some people
> | insisted that EAPIs were numbers (and thus comparable), so I wanted an
> | explicit mention of one that wasn't.
>
The other aspect of it is that they cannot be assumed to be ordered.
You could at some point in the future have a branching hierarchy of
sorts where some EAPIs contain some features and others contain
others, with neither being a superset of the other even accounting for
deprecation.
I get that we haven't generally done that historically, but you
shouldn't be doing ordered/range/etc comparisons with EAPIs (ie "if
EAPI < 5 do this, else do that"). Such things should always be based
on explicit values ("if EAPI in (1,2,3,4) do this, else do that").
--
Rich
