Re: FETCH_USING, removed from pkgsrc HEAD

[David Sainty <dave%dtsp.co.nz@localhost>]

On 14/02/14 10:30, Greg Troxel wrote:
> David Sainty <dave%dtsp.co.nz@localhost> 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
>    fetching
>
> or
>
>    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
>    tnftp_basic)
>
>    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
> off.

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).