Lowercase Perl packages names

[Omikorin]

Resolves #6623

I've taken steps described below:

1. Added _perlname usage everywhere. There are some always-lowercased exceptions but consistency is more important when thinking about possible future scripting. I found even a reversed "standarization" that went from lowercase to uppercase :D
2. Fixed some leftovers that automated script didn't cover like really rare and old _perlmod
3. Renamed all deps inside depends-like arrays for Perl packages
4. Made Perl provides lowercase and updated the patchprov script. I didn't actually ran the script for clarity because it would update some dependencies and change their order.
5. Added conflicts, provides, replaces

It would be better to merge this PR before #6620, #6621, and #6619, so rebasing this monstrosity won't be so harsh.

There won't by any additional cleanup in this PR.

[lazka]

That's in theory a breaking change, it would need to provide both variants for some time.

[lazka]

Though I'm not sure if there are any users of this we care about, so maybe it's not an issue.

[Omikorin]

I can add them back, good point.

[lazka]

@dscho just to be sure, do these many renames make problems for GFW automations?

[dscho]

@dscho just to be sure, do these many renames make problems for GFW automations?

Thanks for the ping! I think we should be fine, there are a couple of places I'll need to adapt, but nothing causing major heartaches.

[Omikorin]

Hm, it broke, but seems like a CI thing

[dscho]

Hm, it broke, but seems like a CI thing

I don't quite think so, the real culprit is this:

[install] perl-term-table
  loading packages...
  resolving dependencies...
  looking for conflicting packages...
  warning: removing 'perl-term-table-0.028-3' from target list because it conflicts with 'perl-5.42.3-2'

So either this Perl module must be made compatible with the current perl package, or it needs to be excluded from this here PR, I'd think.

[Omikorin]

Okay, I managed to find the culprit.

Perl has the following provides list:

provides=(
          # ...
          'perl-Term-Table=0.024'
          'perl-term-table=0.024'
)

but the `Term-Table` module starts with this:

```bash
_perlname='Term-Table'
_realname="${_perlname,,}"
pkgname="perl-${_realname}"
pkgver=0.028
pkgrel=3

I'm not sure why Perl even provides a different version than the package with the same name.
I shouldn't downgrade already existing package, I think.

@dscho can you explain this bit?

Edit: It probably broke because of the new, explicit provides in Term-Table:

provides=("perl-Term-Table=${pkgver}")
conflicts=('perl-Term-Table')
replaces=('perl-Term-Table')

[dscho]

@Omikorin since perl says that it already provides this module, I guess that it truly is an incompatibility with the current Perl? I only see two ways out: either delete that package in this PR, or make it require an older Perl version.

[lazka]

From what I understand both packages should be able to coexist, the perl provided one and the cpan one.

[lazka]

I can't think of a way to fix this though, maybe we should just drop all those provides from perl, to avoid conflicts with the real packages. Or just revert 765bf60 for now.

One could remove the conflicts from Term-Table, but that would break non-system-upgrades. Not supported in theory, but still.

[dscho]

Wasn't there a way to allow certain files in packages to be marked as "user may modify"? I think it was backup. Maybe those are allowed to live in multiple packages simultaneously?

Otherwise the best course of action might be to exclude the perl-term-table files from perl e.g. by deleting them in the package function of the PKGBUILD file (and of course dropping it from the provides array).

[lazka]

perl internals depend on term-table, so I don't think that's possible.

The issue here is that a package wants to conflict on another package, but not on the virtual package of the same name provided by another package. Not something pacman supports. From what I understand.

[Omikorin]

Let me try something. It will need to be fixed for some packages later.

Perl includes dozens of dual-life modules that ship with the core distribution but are also maintained independently on CPAN.
Those packages can be used with a newer version if user wishes so, but if not, then he has the built-in packages available. CPAN modules simply overshadows Perl built-in modules.

From that reasoning, a CPAN module should not have conflicts nor replaces in PKGBUILD. If I'm right, then keeping Perl's both module versions and removing those options from CPAN modules should make them not conflict anymore.

The disadvantage of that solution is if some external package depends on a newer CPAN module then it will revert to using Perl's built-in module.

We can fix that for MINGW packages quickly on the staging level.

[Omikorin]

Hmm, there is no CI workflow running

[lazka]

If there is no replaces then upgrades will fail because pacman could have the old naming installed and tries to install the new named package which has file conflicts.

[Omikorin]

Maybe this d6026f8 will change the situation. Otherwise, we need to revert the commit for double-named built-ins.

[lazka]

(this might work for now, but once the builtin module gets updated on the next perl minor update, things will conflict again)

[Omikorin]

To be honest, if you run patchprov right now, there will be updates like you said.

Can we do it temporarily and freeze Perl with its provides for some time until we remove the uppercased version?

[lazka]

Not quite sure I understand, but I'd be fine with just reverting 765bf60

[Omikorin]

Okay, nevermind. If reverting works then let's do it.

[Omikorin]

Rebased on master branch