Bug 915046 – dev-lang/perl should not depend on app-admin/perl-cleaner

• Product: Gentoo Linux
• Status: IN_PROGRESS ---

[Description sergiotarxz 2023-10-01 17:54:00 UTC]

I thought it would be a nice thing to have the chance to create containers using Portage that only have the packages needed to do whenever they are trying to do.

But when attempted to do so I found that Perl depends on Portage, Python and GCC because its perl-cleaner dependency and that makes it unsuitable to use with slim containers. 

Since perl-cleaner is nothing but a script it could be a dependency of portage instead, but I do not really know how it should be done instead.

The emerge --root feature allowed me previously to make windows executables and other cross compile tricks, but it heavily depends on the runtime dependencies being what it is really needed in runtime.

From my point of view Perl does not need perl-cleaner, instead Portage needs it when Perl is installed.

[Comment 1 Ed Wildgoose 2023-10-11 08:46:29 UTC]

I've just hit the same bug. I use Gentoo as a toolkit to build our embedded router project. We build tiny root file systems and suddenly the build blew up.

Cause seems to be that >= perl-5.16.1 has changed the definition of PDEPEND

Previously we had:

PDEPEND="
	!minimal? (
		>=app-admin/perl-cleaner-2.5

Now we have:

PDEPEND="
	>=app-admin/perl-cleaner-2.30
	!minimal? (
		>=virtual/perl-CPAN-2.290.0

So this change now causes perl-cleaner to be pulled in, which pulls in python, which pulls in some other stuff causing gcc to be pulled in and more.

Seems like this was done as part of the fix for bug #905625 ?

Can I ask for this change to be considered for reverting please?

[Comment 2 Sam James 2023-10-11 08:48:42 UTC]

Yeah, very fair point.

I wonder if we can make both of y'all happy with IDEPEND. That implies you need it for --root but it should be depcleanable.

Does that work for you? (Sorry, I can't experiment with it right this second.)

[Comment 3 Ed Wildgoose 2023-10-11 08:55:25 UTC]

Interesting. I'm not familiar with IDEPEND. 

I build my containers with something like:

ROOT=/some/scratch/space emerge $some_packages

Would this suggestion work for me?

[Comment 4 sergiotarxz 2023-10-11 20:10:23 UTC]

Hi, if IDEPEND will allow running emerge --root whatever --depclean and prune perl-cleaner it is good enough to me.

But I really wonder if there is need of it being dependency at all, I looked up with ripgrep (Grep alternative) the entire /var/db/repos/gentoo and I did not find a single ebuild or eclass that uses perl-cleaner and it is clear (At least for me) that Perl won't ever use it so it looks not like a real dependency of Perl.

Portage would have no problem pulling it as dependency if portage really will use it, the only problem that I can think about is perl-cleaner not depending on portage to avoid a cyclic dependency and that allowing to install it standalone with emerge --root and not working because there is no portage, but, who would do that?

I wonder how much of a problem would be my proposed solution.

[Comment 5 sergiotarxz 2023-10-12 10:24:06 UTC]

Also needing perl-cleaner when running emerge --root cross compiling to Windows to install the binpkg is very problematic since mingw won't be able to compile Python because its pthread dependency, but if you are cross compiling to Windows you will have to heavily modify a lots of ebuilds in order to work so it is a minor problem since there are worse problems in cross compiling to Windows support.

[Comment 6 Larry the Git Cow 2024-05-11 01:58:26 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da43ac9b785133914e0893decb31eddf8eba8aac

commit da43ac9b785133914e0893decb31eddf8eba8aac
Author:     Sam James <[e-mail]>
AuthorDate: 2024-05-11 01:50:13 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-05-11 01:52:20 +0000

    dev-lang/perl: EAPI 8, move app-admin/perl-cleaner from PDEPEND->IDEPEND
    
    Having perl-cleaner in IDEPEND should allow it to be depcleaned with ROOT.
    
    If this ends up not being sufficient, perhaps we should try putting
    it into @system directly, as then people can easily remove it.
    
    Note that I've also adjusted perl-cleaner to move its dev-lang/perl dep
    from RDEPEND->PDEPEND to avoid a circular dependency here now...
    
    Bug: https://bugs.gentoo.org/915046
    Signed-off-by: Sam James <[e-mail]>

 dev-lang/perl/perl-5.38.2-r5.ebuild | 859 ++++++++++++++++++++++++++++++++++++
 1 file changed, 859 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=00aadd9b5059a0675edb18cbb3278059b987ed24

commit 00aadd9b5059a0675edb18cbb3278059b987ed24
Author:     Sam James <[e-mail]>
AuthorDate: 2024-05-11 01:48:29 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-05-11 01:52:20 +0000

    app-admin/perl-cleaner: move dev-lang/perl from RDEPEND->PDEPEND
    
    This is in preparation for moving app-admin/perl-cleaner in dev-lang/perl
    from PDEPEND->IDEPEND to allow depcleaning it with ROOT.
    
    No ebuilds should use perl-cleaner directly so this should be fine.
    
    Bug: https://bugs.gentoo.org/915046
    Signed-off-by: Sam James <[e-mail]>

 app-admin/perl-cleaner/perl-cleaner-2.31-r1.ebuild | 43 ++++++++++++++++++++++
 app-admin/perl-cleaner/perl-cleaner-9999.ebuild    |  3 +-
 2 files changed, 45 insertions(+), 1 deletion(-)

[Comment 7 Sam James 2024-05-11 01:58:44 UTC]

OK, please let me know if this is a bit better now.

[Comment 8 Sam James 2024-05-11 01:59:26 UTC]

(In reply to sergiotarxz from comment #5)
> Also needing perl-cleaner when running emerge --root cross compiling to
> Windows to install the binpkg is very problematic since mingw won't be able
> to compile Python because its pthread dependency, but if you are cross
> compiling to Windows you will have to heavily modify a lots of ebuilds in
> order to work so it is a minor problem since there are worse problems in
> cross compiling to Windows support.

FWIW, I'm happy to look at patches for generally improving cross-to-windows support in Gentoo, even if I won't work on it myself independently.

[Comment 9 sergiotarxz 2024-05-11 22:52:58 UTC]

(In reply to Larry the Git Cow from comment #6)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=da43ac9b785133914e0893decb31eddf8eba8aac
> 
> commit da43ac9b785133914e0893decb31eddf8eba8aac
> Author:     Sam James <[e-mail]>
> AuthorDate: 2024-05-11 01:50:13 +0000
> Commit:     Sam James <[e-mail]>
> CommitDate: 2024-05-11 01:52:20 +0000
> 
>     dev-lang/perl: EAPI 8, move app-admin/perl-cleaner from PDEPEND->IDEPEND
>     
>     Having perl-cleaner in IDEPEND should allow it to be depcleaned with
> ROOT.
>     
>     If this ends up not being sufficient, perhaps we should try putting
>     it into @system directly, as then people can easily remove it.
>     
>     Note that I've also adjusted perl-cleaner to move its dev-lang/perl dep
>     from RDEPEND->PDEPEND to avoid a circular dependency here now...
>     
>     Bug: https://bugs.gentoo.org/915046
>     Signed-off-by: Sam James <[e-mail]>
> 
>  dev-lang/perl/perl-5.38.2-r5.ebuild | 859
> ++++++++++++++++++++++++++++++++++++
>  1 file changed, 859 insertions(+)
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=00aadd9b5059a0675edb18cbb3278059b987ed24
> 
> commit 00aadd9b5059a0675edb18cbb3278059b987ed24
> Author:     Sam James <[e-mail]>
> AuthorDate: 2024-05-11 01:48:29 +0000
> Commit:     Sam James <[e-mail]>
> CommitDate: 2024-05-11 01:52:20 +0000
> 
>     app-admin/perl-cleaner: move dev-lang/perl from RDEPEND->PDEPEND
>     
>     This is in preparation for moving app-admin/perl-cleaner in dev-lang/perl
>     from PDEPEND->IDEPEND to allow depcleaning it with ROOT.
>     
>     No ebuilds should use perl-cleaner directly so this should be fine.
>     
>     Bug: https://bugs.gentoo.org/915046
>     Signed-off-by: Sam James <[e-mail]>
> 
>  app-admin/perl-cleaner/perl-cleaner-2.31-r1.ebuild | 43
> ++++++++++++++++++++++
>  app-admin/perl-cleaner/perl-cleaner-9999.ebuild    |  3 +-
>  2 files changed, 45 insertions(+), 1 deletion(-)
I am making a crossdev environment to test it.
(In reply to Sam James from comment #8)
> (In reply to sergiotarxz from comment #5)
> > Also needing perl-cleaner when running emerge --root cross compiling to
> > Windows to install the binpkg is very problematic since mingw won't be able
> > to compile Python because its pthread dependency, but if you are cross
> > compiling to Windows you will have to heavily modify a lots of ebuilds in
> > order to work so it is a minor problem since there are worse problems in
> > cross compiling to Windows support.
> 
> FWIW, I'm happy to look at patches for generally improving cross-to-windows
> support in Gentoo, even if I won't work on it myself independently.
The problem is it is easy to me to make such patches when I do not have to care about those ebuilds continuing to be useful for actual gentoo, but if I have to care my patches to provide correct behavior in windows and every gentoo architecture I simply do not know how to discriminate, making OS specific patches for meson files and things like that.

I am not very familiar with ebuilds yet and I do not have too much time currently.

[Comment 10 Sam James 2024-05-11 22:57:52 UTC]

(In reply to sergiotarxz from comment #9)
> > FWIW, I'm happy to look at patches for generally improving cross-to-windows
> > support in Gentoo, even if I won't work on it myself independently.
> The problem is it is easy to me to make such patches when I do not have to
> care about those ebuilds continuing to be useful for actual gentoo, but if I
> have to care my patches to provide correct behavior in windows and every
> gentoo architecture I simply do not know how to discriminate, making OS
> specific patches for meson files and things like that.
> 
> I am not very familiar with ebuilds yet and I do not have too much time
> currently.

I understand. The offer is there though and I can at least give guidance on making them generic, and depending on if I can at least understand the Windows problem, may or may not be willing to sometimes fix them up for you.