Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
> On Fri, 13 Aug 2021, David Seifert wrote: > On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote: >> Interesting. You don't even now my view on this but you already have >> an opinion and are saying that I am the culprit. I think this is >> called "prejudiced". > To this day, we're still waiting for your view/statement/rebuttal of the > points, but have yet to receive anything. >> I am pretty sure that as a ComRel member you will abstain >> from this case as you seem to be superior. I mean you are publicly >> attacking me for 10+ months, rejected any attempt from my side when I >> tried to speak with you to get things sorted and now you showed how >> biased your are... > The last message I received from you was on 10 Jul. I have sent 3 > follow-up messages before Monday, 12 Jul (when the Bernd low hit > Germany). Since then, nothing. And before you invoke the Bernd argument: > I'm also a first responder, and while the high Rhine wasn't nearly as > badly affected as the middle Rhine/Eifel area in terms of floodings, I > understand that you might not have had the time to respond (even though > you pushed 19 commits to ::gentoo on 13 Jul). That said, "let me check > whether soap wrote something in PM" seems to have never occurred since > 12 Jul at any point, which raises doubts as to whether this is such a > critical issue after all... Can you please take this discussion private? gentoo-dev is a technical mailing list, and while [1] still qualifies as on-topic (IMHO), the three messages following it in this sub-thread are off-topic here. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/565efeab6f253c402212fd8d8aa58945 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote:
> On 2021-08-08 13:17, David Seifert wrote:
> > So you've created a big commotion... because you didn't get the
> > initial
> > point? Honestly, this seems to be a recurring theme at this point.
> > Someone suggests some improved check/some change, and nowadays you
> > can
> > bet 50 quid that Whissi will pop up and bikeshed it in some way.
>
> No?
>
> First of all, just because you disagree with something or believe a
> discussion is wrong and or not necessary and start to frame it as
> bikeshedding, it doesn't actually become bikeshedding. This is a very
> sad and transparent attempt to silence people through defamation.
>
> The draft contains an error. It's saying that "/etc/tmpfiles.d" became
> deprecated which is not true. Because this would imply that it was
> previously acceptable for packages in Gentoo repository to install to
> that location which is not correct. If a packages in ::gentoo
> installed
> to /etc/tmpfiles.d before, this was already wrong.
>
> And my point was and still is, that neither the commit message nor the
> eqawarn should use the wording "deprecated" because nothing has
> changed
> -- no location became deprecated.
>
> And this will also address parts of antarus' previous mail: Because
> this
> QA check should be only about ::gentoo repository, this shouldn't
> affect
> any other repository. I.e. in your own overlay, you are free to do
> whatever you want and can't be forced to stick to Gentoo QA rules.
>
>
> > It's become a real problem at this point. In fact, we have proxy
> > maintainers publicly refusing to work on packages somehow involving
> > you
> > (I'll mention no names, but check the #-desktop backlog), because
> > your
> > personality boils down to three attributes nowadays:
>
> I am not in that channel and never was. If you make such an
> allegation,
> include facts so that I can respond. If you look at my complete
> history
> at GitHub issues you will find that most people I worked with
> appreciated to work with me. Of course there are some bugs/PRs where I
> rejected a requested change but I am not sure what your point is. This
> is normal because not every PR is valid.
#gentoo-desktop:
[00:00:00] - {Day changed to Friday, 6 August 2021}
[...]
[13:32:33] soap: we went over this last week, 1. I'm not
making any more PRs where I do not receive the recognition I deserve and
2. working with Whissi is probably impossible ;(
[...]
[13:34:50] I'm not sure how well it got through since he
didn't seem to respond to my concerns but I could also tell that he
really has an authoritative decision making style
Timestamps so you can verify it with a third-party. This is a public
statement, I will not share statements by people who have confided in
me.
> > 1. If I say the sky is blue, you'll say it's green. If I say it's
> > green,
> > you'll say it's blue. I've had at least 5 people tell me they see
> > the
> > exact same pattern in you (and no, mgorny is not part of that set,
> > before you throw that point at me). You're the textbook contrarian
> > of
> > Gentoo ("Wutbürger") right now.
> > 2. You'll tell people they are wrong, they aren't following
> > protocols,
> > they made a mistake, but you will never follow through with actually
> > telling people what/why or how. By the time people ask you "why?",
> > you've already disappeared. Given how frequently this happens in
> > multiple channels, projects and at different time points,
> > statistically,
> > this can't be explained by coincidence any more. This happens
> > practically on a daily basis, so you're not getting the benefit of
> > the
> > doubt any more.
> > 3. You can't let go. The security elections disaster right now is
> > the
> > prime example (yes, it's public, just check the history of the
> > Security
> > Project). This captures you so well: it's all about **community**
> > and
> > stuff, until you lose, then you start invoking technicalities and
> > procedural shenanigans to justify some ludicrous kind of "co-lead"
> > crap.
> > Frankly, it's embarrassing, and you're at the centre of it. Instead
> > of
> > accepting defeat (remember, community and democracy!), you just
> > fudge
> > the results.
>
> Interesting. You don't even now my view on this but you already have
> an
> opinion and are saying that I am the culprit. I think this is called
> "prejudiced".
To this day, we're still waiting for your view/statement/rebuttal of the
points, but have yet to receive anything.
> I am pretty sure that as a ComRel member you will abstain
> from this case as you seem to be superior. I mean you are publicly
> attacking me for 10+ months, rejected any attempt from my side when I
> tried to speak with you to get things sorted and now you showed how
> biased your are...
The last message I received from you was on 10 Jul. I have sent 3
follow-up messages before Monday, 12 Jul (when the Bernd low hit
Germany). Since then,
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-08 13:17, David Seifert wrote:
So you've created a big commotion... because you didn't get the initial
point? Honestly, this seems to be a recurring theme at this point.
Someone suggests some improved check/some change, and nowadays you can
bet 50 quid that Whissi will pop up and bikeshed it in some way.
No?
First of all, just because you disagree with something or believe a
discussion is wrong and or not necessary and start to frame it as
bikeshedding, it doesn't actually become bikeshedding. This is a very
sad and transparent attempt to silence people through defamation.
The draft contains an error. It's saying that "/etc/tmpfiles.d" became
deprecated which is not true. Because this would imply that it was
previously acceptable for packages in Gentoo repository to install to
that location which is not correct. If a packages in ::gentoo installed
to /etc/tmpfiles.d before, this was already wrong.
And my point was and still is, that neither the commit message nor the
eqawarn should use the wording "deprecated" because nothing has changed
-- no location became deprecated.
And this will also address parts of antarus' previous mail: Because this
QA check should be only about ::gentoo repository, this shouldn't affect
any other repository. I.e. in your own overlay, you are free to do
whatever you want and can't be forced to stick to Gentoo QA rules.
It's become a real problem at this point. In fact, we have proxy
maintainers publicly refusing to work on packages somehow involving you
(I'll mention no names, but check the #-desktop backlog), because your
personality boils down to three attributes nowadays:
I am not in that channel and never was. If you make such an allegation,
include facts so that I can respond. If you look at my complete history
at GitHub issues you will find that most people I worked with
appreciated to work with me. Of course there are some bugs/PRs where I
rejected a requested change but I am not sure what your point is. This
is normal because not every PR is valid.
1. If I say the sky is blue, you'll say it's green. If I say it's green,
you'll say it's blue. I've had at least 5 people tell me they see the
exact same pattern in you (and no, mgorny is not part of that set,
before you throw that point at me). You're the textbook contrarian of
Gentoo ("Wutbürger") right now.
2. You'll tell people they are wrong, they aren't following protocols,
they made a mistake, but you will never follow through with actually
telling people what/why or how. By the time people ask you "why?",
you've already disappeared. Given how frequently this happens in
multiple channels, projects and at different time points, statistically,
this can't be explained by coincidence any more. This happens
practically on a daily basis, so you're not getting the benefit of the
doubt any more.
3. You can't let go. The security elections disaster right now is the
prime example (yes, it's public, just check the history of the Security
Project). This captures you so well: it's all about **community** and
stuff, until you lose, then you start invoking technicalities and
procedural shenanigans to justify some ludicrous kind of "co-lead" crap.
Frankly, it's embarrassing, and you're at the centre of it. Instead of
accepting defeat (remember, community and democracy!), you just fudge
the results.
Interesting. You don't even now my view on this but you already have an
opinion and are saying that I am the culprit. I think this is called
"prejudiced". I am pretty sure that as a ComRel member you will abstain
from this case as you seem to be superior. I mean you are publicly
attacking me for 10+ months, rejected any attempt from my side when I
tried to speak with you to get things sorted and now you showed how
biased your are...
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Wed, 2021-08-04 at 14:35 +0200, Thomas Deutschmann wrote:
> On 2021-08-04 04:56, Sam James wrote:
> > Sure, thanks for the clarification. It's deprecated in the sense of
> > ebuilds installing to it though, right?
>
> Well, it triggered me because saying it's deprecated implies two
> things
> for me:
>
> 1) It was OK for packages to do that in the past
>
> 2) Something has changed upstream
>
> Regarding 1)
> It was never OK for packages to install in that location. That will
> break the override mechanism systemd introduced. I.e. packages were
> and
> are still only allowed to install below /usr (/lib), to allow local
> system administrators to override installed unit/tmpfiles spec by
> placing a file with the same name in the corresponding directory in
> /etc.
>
>
> Regarding 2)
> Nothing has changed upstream regarding these locations.
>
>
> I personally hope that this QA check will never fire in hope we never
> added an ebuild doing something like that but in the end, that's the
> idea of having such a check: To notice something like that, just in
> case ;-)
So you've created a big commotion... because you didn't get the initial
point? Honestly, this seems to be a recurring theme at this point.
Someone suggests some improved check/some change, and nowadays you can
bet 50 quid that Whissi will pop up and bikeshed it in some way.
It's become a real problem at this point. In fact, we have proxy
maintainers publicly refusing to work on packages somehow involving you
(I'll mention no names, but check the #-desktop backlog), because your
personality boils down to three attributes nowadays:
1. If I say the sky is blue, you'll say it's green. If I say it's green,
you'll say it's blue. I've had at least 5 people tell me they see the
exact same pattern in you (and no, mgorny is not part of that set,
before you throw that point at me). You're the textbook contrarian of
Gentoo ("Wutbürger") right now.
2. You'll tell people they are wrong, they aren't following protocols,
they made a mistake, but you will never follow through with actually
telling people what/why or how. By the time people ask you "why?",
you've already disappeared. Given how frequently this happens in
multiple channels, projects and at different time points, statistically,
this can't be explained by coincidence any more. This happens
practically on a daily basis, so you're not getting the benefit of the
doubt any more.
3. You can't let go. The security elections disaster right now is the
prime example (yes, it's public, just check the history of the Security
Project). This captures you so well: it's all about **community** and
stuff, until you lose, then you start invoking technicalities and
procedural shenanigans to justify some ludicrous kind of "co-lead" crap.
Frankly, it's embarrassing, and you're at the centre of it. Instead of
accepting defeat (remember, community and democracy!), you just fudge
the results.
At this point, you should really reflect on your current standing in
Gentoo. I'm not saying this to disparage you, but to appeal to some kind
of self-respect.
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Wed, Aug 4, 2021 at 5:35 AM Thomas Deutschmann wrote: > > On 2021-08-04 04:56, Sam James wrote: > > Sure, thanks for the clarification. It's deprecated in the sense of > > ebuilds installing to it though, right? > > Well, it triggered me because saying it's deprecated implies two things > for me: > > 1) It was OK for packages to do that in the past > > 2) Something has changed upstream > > Regarding 1) > It was never OK for packages to install in that location. That will > break the override mechanism systemd introduced. I.e. packages were and > are still only allowed to install below /usr (/lib), to allow local > system administrators to override installed unit/tmpfiles spec by > placing a file with the same name in the corresponding directory in /etc. > > > Regarding 2) > Nothing has changed upstream regarding these locations. Maybe next time, just explain that the first time around? Your first email provides no actionable information and requires the other party to expend effort (and wait for a reply) to understand what you mean.
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Tue, Aug 3, 2021 at 7:56 PM Sam James wrote: > > > > > On 4 Aug 2021, at 03:39, Thomas Deutschmann wrote: > > > > On 2021-08-01 01:56, Sam James wrote: > >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which > >> is a deprecated location; > > > > This location is _not_ deprecated. > > > > This is the location for the local system administrator to override > > tmpfiles.d specifications installed by packages which should install below > > /usr. > > > > > > Sure, thanks for the clarification. It's deprecated in the sense of ebuilds > installing to it though, right? What if I use ebuilds to configure my local system settings? ;) -A > > best, > sam
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-04 04:56, Sam James wrote: Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right? Well, it triggered me because saying it's deprecated implies two things for me: 1) It was OK for packages to do that in the past 2) Something has changed upstream Regarding 1) It was never OK for packages to install in that location. That will break the override mechanism systemd introduced. I.e. packages were and are still only allowed to install below /usr (/lib), to allow local system administrators to override installed unit/tmpfiles spec by placing a file with the same name in the corresponding directory in /etc. Regarding 2) Nothing has changed upstream regarding these locations. I personally hope that this QA check will never fire in hope we never added an ebuild doing something like that but in the end, that's the idea of having such a check: To notice something like that, just in case ;-) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
> On 4 Aug 2021, at 03:39, Thomas Deutschmann wrote: > > On 2021-08-01 01:56, Sam James wrote: >> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which >> is a deprecated location; > > This location is _not_ deprecated. > > This is the location for the local system administrator to override > tmpfiles.d specifications installed by packages which should install below > /usr. > > Sure, thanks for the clarification. It's deprecated in the sense of ebuilds installing to it though, right? best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-01 01:56, Sam James wrote: 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which is a deprecated location; This location is _not_ deprecated. This is the location for the local system administrator to override tmpfiles.d specifications installed by packages which should install below /usr. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
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
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 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 Sun, Aug 1, 2021 at 1:24 PM Sam James wrote:
>
>
>
> > On 1 Aug 2021, at 17:42, Mike Gilbert wrote:
> >
> > On Sat, Jul 31, 2021 at 7:56 PM 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;
> >
> > sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get
> > confused by a missing directory.
> >
> > How would you suggest I avoid this QA warning?
>
> We can change the check to be for installing files within the directory?
Works for me. Note that keepdir actually installs a dotfile,
(.keep-${CATEGORY}_${PN}-${SLOT}), so we would want to exclude that.
Also, systemd-tmpfiles looks for *.conf and ignores other files, so we
could probably ignore them too.
Maybe something like this:
files=( "${ED}"/etc/tmpfiles.d/*.conf )
if [[ ${#files[@]} -gt 0 ]]; then
...
> >
> >> 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).
> >
> > sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but
> > calling tmpfiles_process would probably not make much sense.
> >
> > How would you suggest I avoid this QA warning?
> >
>
> We'll probably hardcode a list of folks who need to do this:
> - sys-libs/pam
> - sys-apps/systemd
> (I'll check for any others, but I don't believe there are any now).
>
> How about that?
I'm not crazy about hard-coding package names inside a QA check.
Personally, I would prefer a magic variable I could set to disable the
check from the ebuild side.
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
> On 1 Aug 2021, at 17:42, Mike Gilbert wrote: > > On Sat, Jul 31, 2021 at 7:56 PM 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; > > sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get > confused by a missing directory. > > How would you suggest I avoid this QA warning? We can change the check to be for installing files within the directory? > >> 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). > > sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but > calling tmpfiles_process would probably not make much sense. > > How would you suggest I avoid this QA warning? > We'll probably hardcode a list of folks who need to do this: - sys-libs/pam - sys-apps/systemd (I'll check for any others, but I don't believe there are any now). How about that? best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Sat, Jul 31, 2021 at 7:56 PM 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; sys-apps/systemd calls keepdir /etc/tmpfiles.d so that users don't get confused by a missing directory. How would you suggest I avoid this QA warning? > 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). sys-apps/systemd installs many files in /usr/lib/tmpfiles.d, but calling tmpfiles_process would probably not make much sense. How would you suggest I avoid this QA warning?
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Sun, 2021-08-01 at 00:56 +0100, 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
Nit: normally quoting is not necessary inside [[ ... ]].
> + 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
> + 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,
Michał Górny
[gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
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
+ 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
--
2.32.0
