Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item v2
On 27/02/2024 07:26, Ulrich Mueller wrote: On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote: Title: installkernel is no longer implicitly installed Author: Andrew Ammerlaan Posted: 2024-02-26 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-kernel/installkernel Display-If-Installed: >=sys-apps/debianutils-5.14-r1 Display-If-Installed: app-misc/ca-certificates I have only some small remarks about spelling and style: Thanks for your comments. Here's version 2: Title: installkernel is no longer implicitly installed Author: Andrew Ammerlaan Posted: 2024-02-26 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-kernel/installkernel Display-If-Installed: >=sys-apps/debianutils-5.14-r1 Display-If-Installed: app-misc/ca-certificates /sbin/installkernel is a script called by the kernel's "make install" as well as by the distribution kernel's post-install phase. If you are reading this then chances are you use and rely on installkernel[1] and what follows is essential for you. Previously sys-kernel/installkernel was implicitly installed on many systems via a dependency in sys-apps/debianutils. This dependency was toggled by the "installkernel" USE flag, and enabled by default. Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. This is no longer the case.[2]. As a result many users may find that sys-apps/debianutils and therefore sys-kernel/installkernel are no longer part of the dependency graph and will therefore be cleaned up by "emerge --depclean". Removing sys-kernel/installkernel from your system WILL change the way kernels are installed by "make install"! Instead of the versioned /boot/vmlinuz-x.y.z that you are used to, "make install" will simply copy bzImage (or equivalent for your arch) into /boot. This image may not be picked up by your bootloader or its configuration tools. To avoid surprises from such implicit dependencies from happening again in the future, the dependency on sys-kernel/installkernel in sys-apps/debianutils is removed. And as such, sys-kernel/installkernel is only installed on the system if it is either explicitly selected or pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)). User Action Required (all users) Users who currently have sys-kernel/installkernel installed, must ensure that it is explicitly selected by emerging it: emerge --noreplace sys-kernel/installkernel Users who find that sys-kernel/installkernel has already been cleaned from their systems and are therefore effected by the change in kernel installation described above should re-install sys-kernel/installkernel and then re-install their kernel. emerge sys-kernel/installkernel cd /usr/src/linux # (or other location of the kernel sources) make install Note that this re-installation is not required for users of the distribution kernels (e.g. gentoo-kernel(-bin)). [1] https://wiki.gentoo.org/wiki/Installkernel [2] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e6ccafd58bc7401fa371d2f255d72ddae0131e6
Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
> On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote:
> Title: installkernel is no longer implicitly installed
> Author: Andrew Ammerlaan
> Posted: 2024-02-26
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-kernel/installkernel
> Display-If-Installed: >=sys-apps/debianutils-5.14-r1
> Display-If-Installed: app-misc/ca-certificates
I have only some small remarks about spelling and style:
> /sbin/installkernel is a script called by the kernels 'make install' as well
s/kernels/kernel's/ (also occurs more times below)
> as by the distribution kernels post install phase. If you are reading this
> then chances are you use and rely on installkernel and what follows is
> essential for you.
> Previously sys-kernel/installkernel was implicitly installed on many systems
> via a dependency in sys-apps/debianutils. This dependency was toggled
> by the "installkernel" USE flag, and enabled by default.
Use either double quotes (which I'd prefer) or single quotes throughout.
> sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
> an essential package installed on many systems. However, this
> dependency was recently removed. As a result many users may find that
> sys-apps/debianutils and therefore sys-kernel/installkernel are no longer
> part of the dependency graph and will therefore be cleaned up by
> 'emerge --depclean'.
> Removing sys-kernel/installkernel from your system WILL change the
> way kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image
s/you/your/
> may not be picked up by your bootloader or its configuration tools.
> To avoid surprises from such implicit dependencies from happening
> again in the future, the dependency on sys-kernel/installkernel in
> sys-apps/debianutils is removed. And as such sys-kernel/installkernel
Comma after "such"?
> is only installed on the system if it is either explicitly selected or
> pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)).
> User Action Required (all users)
>
> Users who currently have sys-kernel/installkernel installed, must
> ensure that it is explicitly selected by explicitly emerging it:
Avoid the double "explicitly".
> emerge --noreplace sys-kernel/installkernel
Put a # sign in front to make clear that it's a command? Alternatively,
indent the line (applies also for the three commands below).
> Users who find that sys-kernel/installkernel has already been
> cleaned from their systems and are therefore effected by
> the change in kernel installation described above should
> re-install sys-kernel/installkernel and then re-install their
> kernel.
Above you wrap lines at 75 chars, but here it's down to 60.
Please make it consistent. GLEP 42 suggests "The text body should be
wrapped at 72 characters."
> emerge sys-kernel/installkernel
> cd /usr/src/linux (or other location of the kernel sources)
bash: syntax error near unexpected token `('
But seriously, some users will copy and paste these commands, so making
it a bash comment starting with # may be better.
> make install
> Note that this re-installation is not required for users of the
> distribution kernels (e.g. gentoo-kernel(-bin)).
> See also: https://wiki.gentoo.org/wiki/Installkernel
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item
On 27/02/2024 04:55, Duncan wrote:
Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
excerpted:
Removing sys-kernel/installkernel from your system WILL change the way
kernels are installed by 'make install'! Instead of the versioned
/boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
copy bzImage (or equivalent for you arch) into /boot. This image may not
be picked up by your bootloader or its configuration tools.
I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".
That isn't the case here -- I've been getting versioned images without the
debianutils-based installkernel script for years.
I'm going to disagree here, this *is* the case. If you have it installed
and remove it, then the way the kernel is installed will change.
The point is that I have seen *many* users on our various support
channels that thought they either:
- did not use installkernel before when they actually did and therefore
disregard the instructions in the news item, or
- thought the news item did not apply to them because they misunderstand
what 'make install' does, and therefore disregard essential instructions
in the news item, or
- complain that they don't want automation, when they have in fact been
using this tool for ages. Then remove installkernel.
Such misunderstandings can, and have, lead to systems breaking. I do not
want this to happen again and therefore I want it to be very clear that
if you remove installkernel that this will change things for you.
I long ago (when installkernel was still part of debianutils according to
comments in my version, presumably the debianutils default-enabled USE was
set when it was split out to avoid just this sort of surprise at that
time) created my own version based on the debianutils version, but
bashified/comment-and-var-name-clarified and with a config file that
determines various behavior (along with behavior for my other kernel-
related build/patch/config/etc scripts).
Yes sure, you can make your own /sbin/installkernel. And that means you
don't have sys-kernel/installkernel installed and therefore none of this
applies to you.
But for users that do have it installed now, and have it depcleaned,
behavior is changed always. It is therefore not a case of "will likely"
because it will always.
As a side note, latest version of installkernel also supports reading a
config (install.conf), not sure if this suits your needs but might be
worth to check out.
Maybe "will likely", or "will, unless you've specifically configured other
behavior", or "will, unless you've previously setup your own solution"?
("Will" can then be SHOUTED or not, as desired, because the statement is
then sufficiently conditional regardless.)
If you have setup your own solution, then you a) don't have this package
installed to begin with, and b) clearly know what you are doing. This
news item is for those users that a) do currently have installkernel
installed and b) often don't know the intricacies of what 'make install'
and installkernel do.
Best regards,
Andrew
Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
On 27/02/2024 03:28, Oskari Pirhonen wrote: On Mon, Feb 26, 2024 at 22:39:13 +, Lucio Sauer wrote: On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote: Previously sys-kernel/installkernel was implicitly installed on many systems via a dependency in sys-apps/debianutils. This dependency was toggled by the "installkernel" USE flag, and enabled by default. sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. However, this dependency was recently removed. In my opinion, the last sentence reads as if app-misc/ca-certificates was recently removed. I suggest rewording the passage as follows: Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. This is no longer the case. As a result many users may find that ... Agreed. I was confused for a second reading it since it was the first I'd heard of ca-certificates being removed before I realized that was not the case at all. - Oskari Yes I see how this wording can be confusing. Fixed locally and in the GitHub PR, Thanks. Best regards, Andrew
Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item
On 2/26/24 10:55 PM, Duncan wrote: > Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as > excerpted: > >> Removing sys-kernel/installkernel from your system WILL change the way >> kernels are installed by 'make install'! Instead of the versioned >> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply >> copy bzImage (or equivalent for you arch) into /boot. This image may not >> be picked up by your bootloader or its configuration tools. > > I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL". > > That isn't the case here -- I've been getting versioned images without the > debianutils-based installkernel script for years. > > I long ago (when installkernel was still part of debianutils according to > comments in my version, presumably the debianutils default-enabled USE was > set when it was split out to avoid just this sort of surprise at that > time) created my own version based on the debianutils version, but > bashified/comment-and-var-name-clarified and with a config file that > determines various behavior (along with behavior for my other kernel- > related build/patch/config/etc scripts). Gentoo comes with several different installkernel options, and the critical thing here is that you need to *have* a program called `installkernel`. Via the package manager provided functionality, that means the "installkernel" package. There has been a lot of flux over the last few months. It used to be "installkernel" or "installkernel-systemd", or even "installkernel-gentoo". Surely, anyone can package an alternative installkernel in their overlay. Do we need a virtual/installkernel for this? Is that the only way to set the desired tone in the news item? I'm okay with news items having an implicit "the contents of this news item apply unless you have reimplemented the stated packages in ways that gentoo doesn't officially package and without using an overlay". Or even more simply, all news items have an implicit "unless you know better, including that you know *why* you know better". Someone could be writing that `installkernel` script for use with a kernel package that has an actual RDEPEND on sys-kernel/installkernel, too. Nothing changes. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item
Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
excerpted:
> Removing sys-kernel/installkernel from your system WILL change the way
> kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image may not
> be picked up by your bootloader or its configuration tools.
I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".
That isn't the case here -- I've been getting versioned images without the
debianutils-based installkernel script for years.
I long ago (when installkernel was still part of debianutils according to
comments in my version, presumably the debianutils default-enabled USE was
set when it was split out to avoid just this sort of surprise at that
time) created my own version based on the debianutils version, but
bashified/comment-and-var-name-clarified and with a config file that
determines various behavior (along with behavior for my other kernel-
related build/patch/config/etc scripts).
Maybe "will likely", or "will, unless you've specifically configured other
behavior", or "will, unless you've previously setup your own solution"?
("Will" can then be SHOUTED or not, as desired, because the statement is
then sufficiently conditional regardless.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
On Mon, Feb 26, 2024 at 22:39:13 +, Lucio Sauer wrote: > On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote: > > Previously sys-kernel/installkernel was implicitly installed on many systems > > via a dependency in sys-apps/debianutils. This dependency was toggled > > by the "installkernel" USE flag, and enabled by default. > > > > sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, > > an essential package installed on many systems. However, this > > dependency was recently removed. > > In my opinion, the last sentence reads as if app-misc/ca-certificates was > recently removed. I suggest rewording the passage as follows: > > Until recently, sys-apps/debianutils was in turn pulled in by > app-misc/ca-certificates, an essential package installed on many systems. > This is no longer the case. > > > As a result many users may find that ... > Agreed. I was confused for a second reading it since it was the first I'd heard of ca-certificates being removed before I realized that was not the case at all. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote: > Previously sys-kernel/installkernel was implicitly installed on many systems > via a dependency in sys-apps/debianutils. This dependency was toggled > by the "installkernel" USE flag, and enabled by default. > > sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, > an essential package installed on many systems. However, this > dependency was recently removed. In my opinion, the last sentence reads as if app-misc/ca-certificates was recently removed. I suggest rewording the passage as follows: Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. This is no longer the case. > As a result many users may find that ... Best, -- Lucio Sauer signature.asc Description: PGP signature
[gentoo-dev] [PATCH] java-ant-2.eclass: change JAVA_ANT_E_DEPEND to dev-java/ant
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-ant-2.eclass | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass
index 35fe84997563..f29a8d749227 100644
--- a/eclass/java-ant-2.eclass
+++ b/eclass/java-ant-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 2004-2023 Gentoo Authors
+# Copyright 2004-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: java-ant-2.eclass
@@ -51,10 +51,16 @@ inherit java-utils-2 multilib
# @ECLASS_VARIABLE: JAVA_ANT_DISABLE_ANT_CORE_DEP
# @DEFAULT_UNSET
# @DESCRIPTION:
-# Setting this variable non-empty before inheriting java-ant-2 disables adding
-# dev-java/ant-core into DEPEND.
+# Setting this variable non-empty before inheriting java-ant-2 disables
+# adding dev-java/ant into DEPEND.
+
+# @VARIABLE: JAVA_ANT_E_DEPEND
+# @INTERNAL
+# @DESCRIPTION:
+# Convenience variable adding packages to DEPEND so they need not be added
+# in the ebuild.
if [[ -z "${JAVA_ANT_DISABLE_ANT_CORE_DEP}" ]]; then
- JAVA_ANT_E_DEPEND+=" >=dev-java/ant-core-1.8.2:0"
+ JAVA_ANT_E_DEPEND+=" >=dev-java/ant-1.10.14-r2:0"
fi
# add ant tasks specified in WANT_ANT_TASKS to DEPEND
--
2.41.0
[gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
This draft news item accompanies: https://github.com/gentoo/gentoo/pull/35533 Random packages requiring some tool from Debian should not cause the kernel installation process to change. The dropping of the debianutils dependency in ca-certificates has already caused some surprises due to installkernel being depcleaned. The origin of the problem lies here in debianutils, users unknowingly use and rely on installkernel but do not have it in their world file because it was implicitly pulled in by some package that happens to use the run-parts command. And also the other way around. If I am one of the users that wants to do everything manually, I should not have my 'make install' unknowingly altered by some package that I installed which pulled debianutils into the depgraph. Drop this unused runtime dependency (which is against policy to begin with) and its accompanying flag. This will be accompanied with the following news item: Title: installkernel is no longer implicitly installed Author: Andrew Ammerlaan Posted: 2024-02-26 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-kernel/installkernel Display-If-Installed: >=sys-apps/debianutils-5.14-r1 Display-If-Installed: app-misc/ca-certificates /sbin/installkernel is a script called by the kernels 'make install' as well as by the distribution kernels post install phase. If you are reading this then chances are you use and rely on installkernel and what follows is essential for you. Previously sys-kernel/installkernel was implicitly installed on many systems via a dependency in sys-apps/debianutils. This dependency was toggled by the "installkernel" USE flag, and enabled by default. sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. However, this dependency was recently removed. As a result many users may find that sys-apps/debianutils and therefore sys-kernel/installkernel are no longer part of the dependency graph and will therefore be cleaned up by 'emerge --depclean'. Removing sys-kernel/installkernel from your system WILL change the way kernels are installed by 'make install'! Instead of the versioned /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply copy bzImage (or equivalent for you arch) into /boot. This image may not be picked up by your bootloader or its configuration tools. To avoid surprises from such implicit dependencies from happening again in the future, the dependency on sys-kernel/installkernel in sys-apps/debianutils is removed. And as such sys-kernel/installkernel is only installed on the system if it is either explicitly selected or pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)). User Action Required (all users) Users who currently have sys-kernel/installkernel installed, must ensure that it is explicitly selected by explicitly emerging it: emerge --noreplace sys-kernel/installkernel Users who find that sys-kernel/installkernel has already been cleaned from their systems and are therefore effected by the change in kernel installation described above should re-install sys-kernel/installkernel and then re-install their kernel. emerge sys-kernel/installkernel cd /usr/src/linux (or other location of the kernel sources) make install Note that this re-installation is not required for users of the distribution kernels (e.g. gentoo-kernel(-bin)). See also: https://wiki.gentoo.org/wiki/Installkernel
Re: [gentoo-dev] [PATCH v2 1/2] check-reqs.eclass: runtime disk checks for any path.
On Sun, 2024-02-25 at 22:31 -0800, Robin H. Johnson wrote:
> Allow checking any runtime path for installing ever-larger packages.
>
> CHECKREQS_DISK_RUNTIME=( /boot:40M /:350M /opt:500M )
>
> Recent example of large packages:
>
> gentoo-kernel-bin:
> / >=350MB/version (in /lib/modules)
> /boot >=40MB/version
>
> rust-bin:
> /opt >=450MB/version
>
> Signed-off-by: Robin H. Johnson
> ---
> eclass/check-reqs.eclass | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index fac2f4553d74..1c59c69489a9 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -30,6 +30,13 @@
> # # install will need this much space in /var
> # CHECKREQS_DISK_VAR="1024M"
> #
> +# # install will need this much space in listed paths.
> +# CHECKREQS_DISK_RUNTIME=(
> +# /var:1G
> +# /boot/efi:32M
I'd avoid listing /boot/efi as an example, as /boot is a bit special
and might need special handling in the eclass. In particular,
on the system here I have EFI mounted at /boot, so there
is no /boot/efi.
A possible generic solution would be to "fall back" from non-existing
locations to a "higher" directory, assuming they would normally be
created as subdirectories.
> +# /opt/giant-package-with-dedicated-disk:100G
> +# )
> +#
> # @CODE
> #
> # If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is
> not
> @@ -66,6 +73,11 @@ _CHECK_REQS_ECLASS=1
> # @DESCRIPTION:
> # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
>
> +# @ECLASS_VARIABLE: CHECKREQS_DISK_RUNTIME
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# How much space is needed in paths? Eg.: CHECKREQS_DISK_RUNTIME=( /:1G
> /var:5G )
> +
> # @ECLASS_VARIABLE: CHECKREQS_DONOTHING
> # @USER_VARIABLE
> # @DEFAULT_UNSET
> @@ -120,6 +132,7 @@ _check-reqs_prepare() {
> debug-print-function ${FUNCNAME} "$@"
>
> if [[ -z ${CHECKREQS_MEMORY} &&
> + "${#CHECKREQS_DISK_RUNTIME[@]}" -eq 0 &&
> -z ${CHECKREQS_DISK_BUILD} &&
> -z ${CHECKREQS_DISK_USR} &&
> -z ${CHECKREQS_DISK_VAR} ]]; then
Considering all the extra logic discussed in this thread, it might be
reasonable to implicitly convert CHECKREQS_DISK_* into
CHECKREQS_DISK_RUNTIME, so they'd share all the solutions discussed.
So ideally the logic would be something like:
1. Append CHECKREQS_DISK_* into CHECKREQS_DISK_RUNTIME.
2. Replace missing paths with the first parent directory that exists.
3. Replace paths with their respective mount points.
4. Sum the values corresponding to the same mount point.
> @@ -161,6 +174,16 @@ _check-reqs_run() {
> fi
>
> if [[ ${MERGE_TYPE} != buildonly ]]; then
> + if [[ "${#CHECKREQS_DISK_RUNTIME[@]}" -gt 0 ]]; then
> + for _path_size in "${CHECKREQS_DISK_RUNTIME[@]}"; do
> + _path=${_path_size/:*}
> + _size=${_path_size/*:}
> + _check-reqs_disk \
> + "${EROOT%/}${_path}" "${_size}"
> + done
> + unset _path_size _path _size
Instead of setting them globally, then unsetting, you should use local
variables.
> + fi
> +
> [[ -n ${CHECKREQS_DISK_USR} ]] && \
> _check-reqs_disk \
> "${EROOT%/}/usr" \
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 1/2] check-reqs.eclass: runtime disk checks for any path.
On Mon, Feb 26, 2024 at 08:01:28AM +0100, z...@gentoo.org wrote: > Am 26.02.24 um 07:31 schrieb Robin H. Johnson: > > Allow checking any runtime path for installing ever-larger packages. > > > > CHECKREQS_DISK_RUNTIME=( /boot:40M /:350M /opt:500M ) > > In the example case: Shouldn't the eclass check for 850M on / if /opt is > not a separate partition? > I am not sure how often it really happens that multiple large > requirements for different folders exist. I just summed up the 2 example packages here. I do see your concern about the filesystem/mountpoint layout. If it's a single /: that needs 850M If it's split / and /opt: then it's the listed space in each location. Correctly processing this would require converting each of the listed check locations to their common mounts, summing the needs, and then validating. This should be possible with "stat --printf=%m" to resolve any directory into it's mountpoint. I'll see if it can be done trivially enough for the eclass. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation President & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
