Aleksey Cheusov wrote:
While the current pkg_add(1) does use an external ftp(1) process to access remote repositories, there is no "pluggable" interface to let you choose a different binary to use. You can specify one at compile-time, but the binary must have the exact same interface as ftp(1).This is good. The only thing you need to do is to implement a way to change a fetching program by using environment variable. ftp client (the default) is already in bootstrap. pkgsrc users can adopt their fetching program to ftp's "API" (I did the same thing for Interix/ftp/M$ proxy years ago).
This isn't entirely the whole story, though. The binary must have the same interface as ftp(1), down to all of the commands that it uses and the same return codes. As such, it's not terribly flexible. The existing compile-time switch is there mostly for historical reasons to allow NetBSD users to use their /usr/bin/ftp (which is pkgsrc/net/tnftp) without having to build another FTP client. It it hard to make other "fetch-type" programs, e.g. curl or wget, do look enough like ftp(1) to allow them to be used. That's why I don't consider it a real option right now.
and modernization of the pkg_install codebase is definitely a high-priority project.This is completely different story.
It's not completely different -- ultimately there is a single code base, and my experience with the pkg_install code base is that it's very messy and very hard to work with. Joerg's ongoing improvements make the code much simpler and easier to work with, and again, this allows for adding other features without feeling like you're trying to fit a square peg into a round hole with a sledgehammer.
Joerg's proposed changes now will help make is easier to add new features in the future such as the one you're proposing.I have nothing against modernization, rewtite, refactoring etc. I just think that using "static" library is VERY bad idea. And I don't see chicken-and-eggs problem. ftp client, pax are already in bootstrap.
This isn't a chicken-and-egg problem. This is a conscious choice to reduce the number of things that must be installed as part of the bootstrap process, which I wholeheartedly endorse. If in the future, pkg_install does offer the feature to allow for external programs to fetch using more exotic protocols or methods, we will still want to keep the libfetch code around as a last-ditch fallback so that we don't need to require another program to be installed for proper functioning.
Cheers,
-- Johnny C. Lam