p5-libwww-perl: new version 6.02, which is now in multiple modules distributed separately

[l2g@…]

Gisle Aas broke up the libwww-perl distribution into multiple distributions. (About time?)

So here is the new libwww-perl 6.x family:

• ​libwww-perl
• ​Encode-Locale
• ​File-Listing
• ​HTTP-Cookies
• ​HTTP-Daemon
• ​HTTP-Date
• ​HTTP-Message
• ​HTTP-Negotiate
• ​LWP-MediaTypes
• ​Net-HTTP
• ​WWW-RobotRules

Read the Changes file in libwww-perl, as it mentions some changes with potential to break compatibility in existing scripts that use LWP.

I've played with making portfiles for all of these and can attach them here.

UPDATE (v6.02): To avoid having to install SSL-related files unless they are really needed (I think?), ​LWP::Protocol::https is now distributed separately as well.

[ryandesign@…]

Replying to l2g@…:

• ​HTTP-Date

This portfile was submitted in #29540 and I cleaned it up a bit.

I've played with making portfiles for all of these and can attach them here.

Larry, if you can commit these updates, that would be great. Matthew appears to be busy with other things.

[l2g@…]

I need a little advice on this. Since there will be multiple ports containing the same files as the current p5-libwww-perl port contains, there is a catch-22 when upgrading. MacPorts starts upgrading p5-libwww-perl, then sees the new dependencies. So it tries to bring in the dependencies first. As soon as it hits a port with files overlapping the original p5-libwww-perl, there's a file conflict and the upgrade halts with an error.

This can be worked around by deactivating p5-libwww-perl first, but how best to tell the admin to do that? Or is there a better way to handle something like this?

[ryandesign@…]

I think at this time the best option is the awful pre-activate registry_deactivate hack employed by a handful of ports. See examples in r75570, r74956, r72540.

[l2g@…]

Replying to ryandesign@…:

I see what you mean; it's a bit of a kludge. But I like it better. I'll work on that.

[l2g@…]

Caught one more wrinkle at the last minute. Since libwww-perl 6.02 was released, Mr. Aas has decided to distribute LWP-UserAgent-https separately as well. So, one more port...

[l2g@…]

The above was meant to say "LWP-Protocol-https," not "LWP-UserAgent-https."

It looks like Gisle Aas (the author) wanted to break a circular dependency or avoid some other kind of dependency hell. So LWP::Protocol::https got its own package. Thus, anything needing HTTPS support in LWP should declare dependencies on both LWP and LWP::Protocol::https, and packages that don't need HTTPS don't have to have the extra modules installed.

Now, I'd rather not have to go through all 59 ports depending on LWP to find out whether or not they require HTTPS, or else it'll be a long time before this upgrade gets done.

So my idea is to make an "ssl" variant in this port, and make +ssl the default. Benefits: (1) We keep HTTPS support enabled in the upgrade, following the Principle of Least Astonishment. (2) We allow those who don't want the extra HTTPS modules to disable the variant and uninstall those ports.

In the long term, it would be nicer to go back and audit those p5-libwww-perl dependents, have all those that need HTTPS depend on p5-lwp-protocol-https, then only after all that's done, remove the p5-lwp-protocol-https dependency from p5-libwww-perl.

Phew. That's a mouthful.

Any objections or concerns?

[ryandesign@…]

Sounds fine to me. I'd say proceed at your discretion.

[l2g@…]

Committed (r79379).