search

oetiker / znapzend

zfs backup with remote capabilities and mbuffer integration.
www.znapzend.org
GNU General Public License v3.0
607 stars 137 forks source link

Mojo::IOLoop::ForkCall deprecated, use Mojo::IOLoop::Subprocess instead #494

Closed ahesford closed 3 years ago

ahesford commented 4 years ago

I'm looking to package znapzend for Void Linux, but found that Mojo::IOLoop::ForkCall is marked deprecated by the maintainer. The preferred replacement is Mojo::IOLoop::Subprocess, built right into Mojolicious.

A quick review of znapzend and the Mojo::IOLoop::Subprocess documentation leads me to believe that moving to the preferred replacment is as simple as s/ForkCall/Subprocess/ in lib/ZnapZend.pm and lib/ZnapZend/ZFS.pm, but I am neither a very sophisticated Perl hacker nor terribly familiar with znapzend.

jberger commented 4 years ago

I'm the maintainer of the module in question: (a) yes usually changing the module name is that easy, there are some slight differences especially if you are using the events it emits, but for simple usage it is an easy port and (b) I'm not going to delete it from CPAN any time in the near future. Worst case is it gets less maintenance than I'd normally do. Certainly you should port it so that you get better support from Mojo core but don't fear that I'm going to intentionally cause outages.

oetiker commented 4 years ago

@ahesford will certainly be updating to the new subprocess approach ... but for now, you can just continue using it as is.

ahesford commented 4 years ago

Thank you both for your responses. I am not currently using znapsend but thought I might explore while creating a Void package. Void is also missing a couple of dependencies, including Mojo::IOLoop::ForkCall. Adding a new package for a Perl module labeled deprecated, even knowing that it will persist indefinitely, may raise some eyebrows with the rest of the Void team. This is a back-burner issue for me, so I might let things sit for awhile and reevaluate when interest or necessity demands.

jimklimov commented 4 years ago

Just in case, is this new method introduced recently? A bit back I did have to amend the configure script (and requirements file) to require an older Mojolicious version if running with perl-5.10 for example.

Being quite cross-platform, including Solaris 10 systems still running, znapzend has to support quite a wide range of perl versions and dependencies, at least if that is not prohibitively hard to maintain. Probably this does not mean that an obsolete implementation must remain the only one used - especially if like in this case it is a simple replacement, than some variable for function name, or a wrapper function making the choice, can suffice. And of course an optional include of new dependency, with fallback to old one.

oetiker commented 4 years ago

subprocess has been around for quite some time ...

cgaspar commented 3 years ago

FYI, this has broken the spike repo znapzend RPM on Fedora 33, as there is no longer a perl-Mojo-IOLoop-ForkCall RPM available :-(

jberger commented 3 years ago

Unfortunately system packagers rarely if ever communicate with upstream library authors. I was neither aware that there had been an rpm for it nor that it no longer had one. Personally I always recommend getting your CPAN dependencies from CPAN. Distro packagers do a service, but not one that we CPAN authors can control or even see.

spike77453 commented 3 years ago

FYI, this has broken the spike repo znapzend RPM on Fedora 33, as there is no longer a perl-Mojo-IOLoop-ForkCall RPM available :-(

Sorry about that, it should be fixed now.

ahesford commented 3 years ago

Closing because I'm not really thinking about this anymore.