Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Helmut Grohne <helmut@subdivi.de>]

Hi Niels,

On Thu, Jan 16, 2025 at 06:36:24PM +0100, Niels Thykier wrote:
> Putting the scripts into `devscripts` package would imply that `devscripts`
> becomes part of the `bootstrap essential` set of packages. I am not sure the
> `devscripts` maintainers are interested in that, because it implies you
> cannot arbitrarily add new Dependencies. As an example, if `devscripts`
> depends on even a single `arch:any` perl package, then the next `perl`
> transition could have `debhelper` become uninstallable, which is not going
> to be fun for anyone around at that time.

I think we can skip this discussion.

You cannot make reasonable use of guess_concurrency.py without adding
some code (most commonly that would be adding an option indicating how
much ram you need per core). As a result, you very much know when you
are using it and you may explicitly depend on whatever package contains
it.

Keep in mind that the number of source package that practically benefit
from this is around 100 (maybe half, maybe double, but far from 50%).

If we end up integrating with debhelper, I see this as an optional
integration point. Earlier, I proposed a MR to debhelper embedding the
functionality. If redoing it, we'd still add an option, but in the
absence of that option, no concurrency guessing happens. If the option
is passed, we may call out to an external binary and error out when
missing. As such, I do not see debhelper gaining a new dependency in any
way.

What I dislike about devscripts as a build dependency is that it is
quite big and comes with a number of dependencies not relevant to us.
However, think about the use case. It's only relevant to huge packages
in the first place. Those extra dependencies will not pose a noticeable
extra cost. We already have around 2000 source packages requiring
devscripts (mostly as it is a dependency of gem2deb). So while I was
originally favouring a new binary package, I lack arguments against
devscripts now.

I note that devscripts conveniently depends on python3:any already and
nproc from coreutils happens to be essential.

The question of which package we stuff it in feels more of a bike
colouring one than one relevant to debhelper beyond naming the right
package in the error message.

Helmut