Re: The project
On Tue, 20 Jul 1999, Hamish Moffatt wrote:
# A query about the ports: when they fetch source via FTP, do they have
# an exact version they need, or will they search for the newest and attempt
# to use it?
The majority of the time they get only the one they need. No
searching, no fuss, it is all done transparently. The whole
process is controlled by the port in a manner similar to this.
In the Makefile there are a list of MASTER_SITES and a list
of distfiles that need to be retrieved. The files/md5 lists
each of the distfiles along with its md5 checksum and optionally
its size. Because we use make(1) scripts a build really consists
of several targets. The longest one from a clean port is
usually 'make package'. Note you can do all of these separately
or you can use 'make package' which will do them all in roughly
this order.
1) fetch: if the distfiles aren't in /usr/ports/distfiles,
then try to grab them from the CD (if mounted), otherwise
run through the list of MASTER_SITES and grab them.
2) extract: uncompress (bzip, bzip2, unzip, gzip, ...) the files
into the work directory. They can also be tars, shars, or
uuencoded.
3) patch: use the files in the patches directory to get the
sources into a buildable state.
4) configure: run the GNU configure script if there is one, a
homegrown one from scripts/configure, or NOP if no action
is required.
5) build: compile the port
6) install: copy the files to their final resting place and
register the program with the package manager
7) package: tell the package manager to build a package of this
port.
There are a ton more targets, including pre- and post- versions
of all of the above. You'll find all of them and minimal
documentation in bsd.port.mk. There is also some stuff in
the porting section of the handbook.
Of course, later stages are dependent on the success of
earlier targets. And if this port depends on other ports
to build or run the make(1) scripts will automagically do
the same steps for them (excluding package which isn't recursive)
at various places during the build if they aren't already
installed.
The only time fetch(1) (yes we have a program called fetch that
takes a URI and returns a file with file:, http:, ftp:, ...)
fails is when the upstream provider doesn't use version numbers
on the tarball. Here you will either get a checksum mismatch
after downloading the file. If you have the size reporting
turned on it will usually reject the file because the size has
also changed (no clean way to ask for md5 checksums over http/ftp
that I'm aware or). And last you can do what I do most of the
time, use a variable called MASTER_SITE_OVERRIDE. Set this
variable to point at the main FreeBSD ftp site and you will get
the right one every time if the server hasn't reached its 6000
user limit at the time you hit it.
# No, we don't really have anything like that. In some cases there are
# multiple .debs with different options (eg a console version versus
# an X11 capable version).
Same goes for FreeBSD. Many ports have knobs but we only ship
a package for them with a single set. You want different ones,
we either create multple ports (a2ps-${PAPER_SIZE}) or you grab
the port's sources and tweak them yourself. We did try once to
fixup the package building process in bsd.port.mk to allow a
single port to build multiple packages and it turned out to be
a huge nightmare that didn't gain us much at all that having
multiple ports didn't make a ton easier.
-steve
Reply to: