Package Details: perl-www-curl 4.17-17

Git Clone URL: (read-only, click to copy)
Package Base: perl-www-curl
Description: Perl/CPAN Module WWW::Curl
Upstream URL:
Licenses: GPL, PerlArtistic
Submitter: foutrelis
Maintainer: Erroneous
Last Packager: Erroneous
Votes: 3
Popularity: 0.000060
First Submitted: 2020-06-21 18:35 (UTC)
Last Updated: 2023-08-14 15:43 (UTC)

Latest Comments

j12t commented on 2023-04-08 21:53 (UTC) (edited on 2023-04-08 21:57 (UTC) by j12t)

Fails to build (curl 8 issue?)

curlopt-constants.c:2809:58: error: ‘CURLOPTDEPRECATED’ undeclared (first use in this function);

Macports seems to have a patch:

Erroneous commented on 2022-06-02 10:55 (UTC)

Hello MarsSeed,

Realistically this package should be updated every time libcurl has an ABI change or addition since it grabs symbols from the header file automatically.

My main reason for bumping the pkgrel is to keep versions consistent with breaking dependency changes. If you bumped your own version to -15 and then there was an update to libcurl that broke the build process and I bumped this version to -15 then any systems using your private repo could need to manually update.

What I can start doing is pushing pkgrel bumps for perl versions to a different branch and when there's a change to the build process merge it to main. That way the version should be about consistent with an up to date Arch distribution, but sometimes you might see skips in the pkgrel. Doing a git log would reveal why.

There's really no accounting for delayed downstream distributions using AUR packages. I think AUR packages for them are probably out of scope for what I assume they're trying to accomplish, namely a stable environment. You'll probably find lots of issues with AUR packages which should assume an up to date Arch system.

MarsSeed commented on 2022-06-01 15:48 (UTC)


Please don't do empty bumps of pkgrel next time. It makes sense when you control a binary repo, but the AUR is not a closed build system and the majority of its users are end-users doing their own builds (mostly via AUR helpers).

The [perl] package from Arch has a pacman ALPM hook that warns users if there are perl module files installed in a versioned directory that mismatches the system-installed Perl version.

Therefore the users will know if they need to manually rebuild their AUR-based Perl packages after an upstream [perl] package update.

Then, if you as an AUR package maintainer do this bump, such users have to do that rebuild a second time.

And no, it doesn't help even if you do the bump the same second Arch repo updates its Perl version: because there are downstream distros based on Arch Linux and the users of those can and do use the AUR as well. These downstream repos usually import Arch-built packages with some delay (Manjaro's most conservative stable branch usually has a delay of one month or more.)

For delayed downstream distros, your bump today will cause those distro users to do a superfluous rebuild with the earlier Perl 5.34, because they still have that version. Then, when their distros import the new Perl 5.36, those users still need to rebuild this AUR package manually .

I hope you understand the pain I am expressing on behalf of the average AUR user (who are quite large in number), and decide to accommodate all of us next time by not doing another changeless pkgrel bump.

Thank you.