4 ms·

One thing I've wished for in curl is for the backends ("handlers") to be more pluggable. This would solve a packaging problem we have in Fedora where we'd pref

by rwmj 2y ago

One thing I've wished for in curl is for the backends ("handlers") to be more pluggable. This would solve a packaging problem we have in Fedora where we'd prefer to distribute a core curl with backends packaged as subpackages, so that programs that only need (eg) http support would only need to depend on curl-handler-http and curl-core. At the moment the actual solution is to compile separate curl and curl-minimal packages where curl-minimal removes the lesser-used backends, and you have to choose, system-wide, which one to install. This plus a stable ABI for handlers would also solve the writing backends in other languages problem because another team could contribute a Rust / hyper handler separately. (I'm sure Daniel has solid reasons for not doing this, not to mention that it's a bunch of work which no one is volunteering to do.)

fulafel 2y ago
The curl-minimal solution sounds more transparent and understandable to users, on the other hand.
- rwmj 2y ago
  The problem with curl-minimal is if you install any program that needs full-fat curl, then you're out of luck if you want to keep the minimal install. With separate curl handlers you'd also be able to find out what protocols your system is configured to access with a command like this [simulated]: $ rpm -qa | grep curl-handler- | sort curl-handler-ftp curl-handler-http curl-handler-https curl-handler-smb and similar RPM commands might be used to find out what applications need a particular protocol.
  - fulafel 2y ago
    Yep, but still as a user I'd prefer the simpler way, since it will be more clear what's happening ("ok, curl-minimal is being replaced by the full curl when I install this package"). And there will be fewer little splinter packages. I wonder if there's a place for an additional level of abstraction here, so that the user would just see something like "subcomponent X of the curl package is being installed"...

by rwmj 2y ago

fulafel 2y ago

The curl-minimal solution sounds more transparent and understandable to users, on the other hand.

rwmj 2y ago
The problem with curl-minimal is if you install any program that needs full-fat curl, then you're out of luck if you want to keep the minimal install. With separate curl handlers you'd also be able to find out what protocols your system is configured to access with a command like this [simulated]: $ rpm -qa | grep curl-handler- | sort curl-handler-ftp curl-handler-http curl-handler-https curl-handler-smb and similar RPM commands might be used to find out what applications need a particular protocol.
- fulafel 2y ago
  Yep, but still as a user I'd prefer the simpler way, since it will be more clear what's happening ("ok, curl-minimal is being replaced by the full curl when I install this package"). And there will be fewer little splinter packages. I wonder if there's a place for an additional level of abstraction here, so that the user would just see something like "subcomponent X of the curl package is being installed"...