tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FETCH_USING, removed from pkgsrc HEAD

On 14/02/14 10:30, Greg Troxel wrote:
David Sainty <> writes:

tnftp dependencies are a big bootstrapping and updating hassle.  If it
does grow a new dependencies, it'd be nice if there was also something
like a tnftp_basic package that avoids all dependencies (no ncurses,
no openssl), which was then available during bootstrapping to pull
down ncurses and openssl for the full tnftp.
I'm not sure I understand exactly what you mean, so I'll try to restate
in an overly verbose manner and add some details.

I think we either need to have on each platform

   a) one fetch program already present that can at least do ftp and http
   (not TLS) to fetch distfiles for core things used in programs that do


   b) a fetch program with distfile in files/ that can build without
   fetching anything, which can then serve as item (a)

On NetBSD-6, tnftp builds without dependencies, and links against
terminfo and not openssl, so this is really not a problem.  But
presumably once we added openssl, it would link against builtin there
and pkgsrc in many other places, including netbsd-5 and macosx.

So I think what you mean is:

   let's have tnftp_basic that really has no dependencies, no terminfo,
   no ssl, everything but libc configured off, but built reachover from
   the files/ dir in tnftp.  install a binary ftp_basic.

   then, in tnftp, add a dependency on ssl, and don't worry about the
   consequences (because those who don't like the consequences should use

   in tnftp_basic, openssl, and anything else depended on by tnftp, set a
   variable FETCH_BASIC

   if FETCH_BASIC is set, default to an OS-provided fetch program that
   can do ftp and http, or tnftp_basic if none.  This will trigger
   tnftp_basic to be built.

   if FETCH_BASIC is not set, default to an OS-provided fetch program
   that can additionally do https, or tnftp if none.  This will trigger
   tnftp to be built.

Yes, that's essentially it.

   consider optionally setting FETCH_BASIC in really common small
   packages that are known not to need https to fetch, to avoid openssl
   showing up in minimal installs

I tend to think the Pkgsrc fetching framework could be responsible for that - if it needs to use an https: URL during fetching it selects the full client, if not it can use the basic client.

A justification is that it's possible that a user may be setting one of the MASTER_SITE_* overrides to use a private repository, and may use an https: site in order to do so. Unlikely, but I think that suggests that packages in general [I.e. not a bootstrapping package] should not make the assumption FETCH_BASIC can be used.

   So, if someone takes "bmake package" in some random place, that will
   depend on tnftp, which will depend on openssl, which will depend on
   tnftp_basic, and it will all work.

That would be a nice improvement over now, when bootstrapping without
having the ncurses source requires annoying manual effort.
Does what I said (which is perhaps not much more than just repeating
what you said) sound right to you?  If not, please tell me where I'm

Sounds right.

ncurses is the primary reason I tend towards tnftp_basic + tnftp (rather than, say, going the other way and having tnftp + tnftp_ssl).

Home | Main Index | Thread Index | Old Index