[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg_add and remote packages
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
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
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
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.
-- Johnny C. Lam
Main Index |
Thread Index |