Date: Wed, 29 Nov 1995 02:38:44 -0800 From: asami@cs.berkeley.edu (Satoshi Asami) To: chuckr@glue.umd.edu Cc: FreeBSD-ports@FreeBSD.ORG Subject: Re: misc/colorls Message-ID: <199511291038.CAA01516@silvia.HIP.Berkeley.EDU> In-Reply-To: <Pine.SUN.3.91.951128162332.11766A-100000@mocha.eng.umd.edu> (message from Chuck Robey on Tue, 28 Nov 1995 16:32:49 -0500 (EST))
next in thread | previous in thread | raw e-mail | index | archive | help
* I'm not sure what that option is, is the one where you can give the name * of the directory.tar.gz and have the distant end tar and gzip it for you? * I know that does work, I just tried it under old version 1.7.1 (the one * on my Univ. acct). Try it by giving it the whole path in the command line, not in interactive mode. That's when it breaks. * Anyhow, assuming I'm wrong on what that option means, I have the source * for colorls resident on my system, but the fetch breaks anyhow, looking * for a utility (ncftp2) that it wouldn't even need if it existed. Is this * correct? Shouldn't that depends test be made after it looks locally for * the sources? The problem is, the FETCH_DEPENDS variable is supposed to list things that are required somewhere during the "fetch" phase -- which contains not only the actual fetching, but checking if the file exists or not, etc. We never know what people might want to do inside their custom "do-fetch" target. But I agree that it's kinda screwed right now, maybe FETCH_DEPENDS wasn't such a great idea. We can deal with your particular complaint by violating our design principle of "no dependency checking except in skeleton targets" and move it inside do-fetch, so that it will be done only when a file is not found, but that is a major breach of orthogonality in the design of bsd.port.mk (and orthogonality is about the only thing that is holding this beast together -- at least for me). Also, an additional problem with these "on-the-fly" tarballs is that there is no fixed checksum (we never know when people will change the compression option on the ftp site, for instance), which can give you a problem like below. We can just move these stuff (those that use FETCH_DEPENDS -- all three are mine, and they are pretty small) to freefall's LOCAL_PORTS area and do away with FETCH_DEPENDS. Everyone seems to have his own solution to this problem, for example Jean-Marc uses a small perl script called "ftpget" to fetch files from the CTAN archive (which also does on-the-fly packing). There also is this issue of multiple subdirectories having same names, so the fetch script has to be able to save the file in a name other than "<last component of dirname>.tar.gz". Maybe we can write a small wrapper to ncftp, which will solve all these problems, and put it in the base system (so no FETCH_DEPENDS). (No Jean-Marc, I'm not going to give up on ncftp -- the "progression meter" is too cool to pass up, and is actually *useful* for people like me (sitting behind phone lines). ;) * Finally, I setenv'ed NO_DEPENDS so I could check the next step in spite * of my lack of ncftp2, and the build failed, it was trying to patch a * directory that doesn't exist: * * patch: **** can't cd to * /usr/ports/misc/colorls/work/pub/FreeBSD/FreeBSD-current/src/bin/ls: No * such file or directory * *** Error code 1 * * That directory sure doesn't exist on my machine, does yours have one? Yes, you have an old tarball, or you fetched it in interactive mode in ncftp (see, no checksum!). Try to get the one in ftp.freebsd.org's "distfiles/" dir, that one should work. Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511291038.CAA01516>