Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/12/2017 08:43 AM, Michał Górny wrote:
>
> I'm not convinced a QA warning is valid, given that not every empty
> directory is meaningful. You're going to either cause people to create
> unnecessary 'keepdir's, or to be swamped by false positives.

The warning would essentially be saying, "you installed this empty
directory, do you need it?" Granted, it would be annoying if the answer
was "no" and if my package triggered thirty of them, but then that's a
bug (possibly upstream) that should be reported and fixed. On the other
hand, if you need the directory, then you should be calling "keepdir" on
it -- so in either case I don't think the warning is a false positive.


>>   * Have portage call its keepdir code on any empty directories in $D
>>     between src_install and pkg_preinst.
>
> How does this account for /run and other non-persistent locations?

What specific problem do you foresee?

The implementation above should be no worse than what we have. Right
now, there are a lot of ebuilds that are installing empty directories.
Those ebuilds are buggy in one way or another: either relying on
undefined behavior, or creating unused directories for no reason. (Many
of the first type are not easily fixed, since the upstream build system
creates them.) The "automatic keepdir" would still create unused
directories, but it would fix the directories that should have been
keepdir'd but weren't.

This presents the usual problems with /run, but none that we don't
already have. Ebuilds that create directories under /run already receive
a QA warning not to do that, and those directories are already clobbered
on a reboot; that doesn't change. If a package like baselayout wants to
create an empty /run, it can do so in pkg_postinst to avoid the ".keep"
file. What else am I missing?


>>   * Change the PMS to remove "undefined behavior" and replace it with
>>     "empty directories must be tracked, and may only be removed once no
>>     installed package is using them," or something along those lines.
>>     That leaves the implementation up to the PM.
>
> ...and makes interoperability between different package managers
> impossible, defeating the purpose of PMS in the first place.

Well, that's why I'm asking.. I don't know WTF I'm doing, but I'd still
like the proposal to be decent when I give it to the people who do.