pure_install target does not exist on MB:T

[kentfredric]

https://metacpan.org/module/Module::Build#pure_install

The target ./Build pure_install is documented as a method of Module::Build that will remain pure in the event Module::Build eventually adds support for munging perllocal.pod.

Gentoo have been using this method, despite the fact its current implementation means it is just a proxy for install, because for us, modification of perllocal.pod is both impossible ( fatal access violation ) and the generation of such a file in a DESTDIR= tree is undesirable ( filesystem collision )

I'm not sure if Module::Build has yet implemented perllocal.pod modification, or where MBT stands on the eventual modification of that file.

Either way, the existence of an equivalent method makes MBT more compatible with wrapping code.

[Leont]

The target ./Build pure_install is documented as a method of Module::Build that will remain pure in the event Module::Build eventually adds support for munging perllocal.pod.

Gentoo have been using this method, despite the fact its current implementation means it is just a proxy for install, because for us, modification of perllocal.pod is both impossible ( fatal access violation ) and the generation of such a file in a DESTDIR= tree is undesirable ( filesystem collision )

Sounds reasonable enough.

I'm not sure if Module::Build has yet implemented perllocal.pod modification, or where MBT stands on the eventual modification of that file.

Neither of them implement it currently, but I was planning to do that. It's reasonably high on the todo list

Either way, the existence of an equivalent method makes MBT more compatible with wrapping code.

Personally, I hate the proliferation of install actions. MB now has not only install but also fake_install and pure_install. Both of them really should have been flags instead of separate actions, if only to enable combining them.

I suppose that is a discussion for the Build.PL spec

[powerman]

Is it possible to somehow fix this in general way (i.e. auto-detect MBT in Gentoo's perl-module.eclass) and force using "install" instead of "pure_install"? I'm somewhat tired of adding manually mytargets="install" into each ebuild generated by g-cpan which uses MBT…

Update: Oops, I've just found I've already proposed a patch for this issue at https://bugs.gentoo.org/show_bug.cgi?id=495044 about a year ago. :) So, looks like solution exists, but no one wanna use it.

[kentfredric]

This is not really the place to discuss gentoo interop with MBT ;).

I think the solution you want is to bug g-cpan to inject the right code automatically if it detects MBT, mostly, because eventually we're going to HAVE to have some sort of "Use toolchain X" marker IMHO. Automagicing it at install time is just dangerous given our install time can't dynamically pull in dependencies.

[Leont]

I think the solution you want is to bug g-cpan to inject the right code automatically if it detects MBT

That the defeats the purpose of the spec. I'd rather add --pure to MB (before adding any perllocal support) and have gentoo switch to that.

[kentfredric]

That the defeats the purpose of the spec. I'd rather add --pure to MB (before adding any perllocal support) and have gentoo switch to that.

Unforutnately, that just brings the problem back, because we'll have to, in order to support that, know whether the module in question uses MB or MBT, and then inject dependency on only one of those two of the required minimum version to support --pure

And we can't inject dependencies after existing dependencies are specified in the ebuild itself due to how ebuilds work. ( We can inject dependencies earlier based on some other variable if its placed in the right location, but reading DEPEND= and augmenting it based on something being inside it is presently not possible as far as I'm aware. )

This can work:

PERL_TOOLKIT="mb"
inherit perl-module  # inject version upgrades due to 'mb' existing 
DEPEND="virutal/perl-Module-Build"

This can't

inherit perl-module  # injections can only happen here and DEPEND doesnt exist yet 
DEPEND="virutal/perl-Module-Build"

[Leont]

Unforutnately, that just brings the problem back, because we'll have to, in order to support that, know whether the module in question uses MB or MBT, and then inject dependency on only one of those two of the required minimum version to support --pure

No it doesn't. The install action is already pure today for both. It's not guaranteed to stay pure in the future. Or am I missing something?

And we can't inject dependencies after existing dependencies are specified in the ebuild itself due to how ebuilds work. ( We can inject dependencies earlier based on some other variable if its placed in the right location, but reading DEPEND= and augmenting it based on something being inside it is presently not possible as far as I'm aware. )

It's not clear to me what you mean here, I'm only superficially familiar with Gentoo terminology.

[powerman]

@Leont, if you just add support for pure_install target it will be enough. But if you'll instead add, say, --pure option to install target - we'll still have to handle MB and MBT in different ways, which mean we'll have to detect which one of them is used by current perl module.

[kentfredric]

No it doesn't. The install action is already pure today for both. It's not guaranteed to stay pure in the future. Or am I missing something?

Oh. I see, for some reason I was expecting passing --pure and it not being supported to explode. Having now tested it and seeing that it doesn't explode I'll communicate that fact to the right place and we might be able to fix this. =)

It's not clear to me what you mean here, I'm only superficially familiar with Gentoo terminology.

Its really mostly due to the fact we need some such markers anyway for QA purposes, because periodically, upstream change how they tool things, but gentoo downstream developers fail to update dependencies respectively.

And the result is you have code building where the dependencies may not be satisfied, and there being no automatic way to satisfy them, leading to a downstream brekage for users.

Hence, we need some sort of QA process to make sure that the code being built matches the expectations outlined in the ebuild.

And its much more straight forward and failsafe to have a system where we declare "I expect this distrubition to need Module::Build::Tiny" and have code validate that belief, than it is to do it the other way around. But thats more aspects of our downstream QA process where obvious forward declarations of "How will this be built" need to be vivid and readable by the users installer long in advance of the .tar.gz's being fetched from CPAN.

Gentoo workflow for users is:

1. Read ebuilds
2. Analyse dependencies
3. Plan install graph
4. Iterate graph (build/install cycle)
5. foreach item:
   1. fetch sources
   2. run source configure etc
   3. run build etc
   4. (optional) run tests
   5. run fake install to a mock tree
   6. copy mock tree to /

5.iii can't change 2, 3 or 4, so that is where we place QA checks to make sure the sources and the build recipie are somewhat cohesive, in the hope that somebody will install it and notice that QA warning if it occurs while the ebuild in question is in "testing" so that its advice is heeded prior to stabilization, as it is unacceptable for stable ebuilds to fail at any point in installation or require manual intervention after the graph iteration has begun, and as much configuration/error detection as possible should occur before the main install loop. breathes

[kentfredric]

I think what we could ask for here now is simply to document that

• Module::Build presently and has always supported doing ./Build --pure
• Module::Build::Tiny presently and has always supported doing ./Build --pure
• That both have always supported this due to it being a non-op that was simply not failed on
• That both have always done pure installs by default
• And that if non-pure installs ever become a thing, --pure will be the path forward to keep using Pure installs.

If all those claims are indeed true, and can be documented as such as guarantees of sorts, I believe we can codify to that standard.

[Leont]

if you just add support for pure_install target it will be enough.

I won't, unless the Build.PL process concludes otherwise (which I don't think it will)

But if you'll instead add, say, --pure option to install target - we'll still have to handle MB and MBT in different ways, which mean we'll have to detect which one of them is used by current perl module.

I also maintain MB., keeping them in sync is the easy part. And what @kentfredric just said.