From owner-freebsd-ports Thu Aug 21 21:45:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA14445 for ports-outgoing; Thu, 21 Aug 1997 21:45:55 -0700 (PDT) Received: from x22 (ppp6467.on.sympatico.ca [206.172.208.59]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA14434 for ; Thu, 21 Aug 1997 21:45:39 -0700 (PDT) Received: from localhost (tim@localhost) by x22 (8.8.5/8.7.3) with SMTP id AAA00380; Fri, 22 Aug 1997 00:43:07 -0400 (EDT) Date: Fri, 22 Aug 1997 00:43:06 -0400 (EDT) From: Tim Vanderhoek Reply-To: ac199@hwcn.org To: Bill Fenner cc: hoek@hwcn.org, asami@cs.berkeley.edu, freebsd-ports@freebsd.org Subject: Re: Versioning bsd.port.mk In-Reply-To: <97Aug21.171248pdt.177486@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 21 Aug 1997, Bill Fenner wrote: > >But, please don't put the MK_VER_REQ file in files/, put in pkg/ > >with all of everything else. We already have pkg/MD5 which is > >totally irrelavent to packaging, so this will fit in just finely. :) > > Uh, do you mean files/md5? (which is why I suggested putting this > other requirement file in files/) Uh... Ya. I do. Which suggests that MK_VER_REQ (or whatever) belongs in files/, too... > The port Makefile is exactly what depends on bsd.port.mk, which is why > I suggested putting it there. Using ${SH} in port Makefiles is what > started this thread. And not every port needs it -- only ports with > complex Makefiles that use newer bsd.port.mk files - another reason to > link the requirement with the Makefile. The port Makefile contains information describing how to compile and install a 3rd party piece of software. I think it's best to try and keep that as pure and simple as possible. If the variable is put in the Makefile, the Makefile will become that much more complicated. Where to put it? Ensure it's not been forgotten. Etc. By using a files/file, it can be done silently and invisibly. Yes, every port should depend on a specific revision of bsd.port.mk, not just the complex ones. The specific ${SH} may have only applied to the complex ones, but a gazillion other changes could affect even the simple port Makefiles. Versioning only the complex ports will just create more confusion when the simpler ones break (which I think will happen). Note that the Makefiles depend on more than bsd.port.mk. Are we going to document every single dependency of each Makefile inside the Makefile? Of course, it's also more than the Makefiles which depend on bsd.port.mk. It's the whole port which depends on bsd.port.mk, this includes patches/*, files/md5, pkg/PLIST, etc. Finally, I just plain don't like having my Makefiles machine-editted. :-) Itojun just posted a nice patch which looks about right. I don't think it would hurt to make the warning about old bsd.port.mk's somewhat stronger, though. "UPGRADE YOUR PORTS SYSTEM OR EVERYTHING MAY GO WRONG!!!". Or something. :) Without being too wordy, it should tell how to upgrade, why, how to forgoe the check, and a disclaimer for those who do forgoe the check. "Your ports subsystem is outdated." "See Handbook section 4.7 to upgrade" "Use ``make NO_CHECKSTAMP=yes [other args]'' to skip" "this check [not advised!]" Ugh. I guess this would require submitting a patch to handbook section 4.7, too... Q. How do I upgrade my ports subsystem? A. The port skeleton of every port depends on other parts of your system, the most crucial part being the ``ports subsystem''. Sometimes it is possible to have a skeleton for a port which is newer and not compatible with your ports subsystem. Versions of FreeBSD after (and including) 2.2.5 will warn you when you need to upgrade your ports subsystem, but FreeBSD prior to that assumes that you regularly upgrade the ports subsystem yourself. FreeBSD provides an easy way for most people to upgrade their ports subsystem through, ironically enough, its mortal enemy the package system. On ftp.freebsd.org, in the package directory for the last release of FreeBSD, you should be able to find files named ###upgrade-##.##.##.tgz, where the hash marks (aka. pound symbols), #'s, are replaced with the FreeBSD version and the date. At time of writing, the most recent upgrade package is /pub/FreeBSD/packages-2.2.2/222upgrade-97.07.21.tgz. You should download this file and use pkg_add(1) to install it. If, after properly installing the latest upgrade package, you are still warned that your ports subsystem is out of date, you have three remaining options. * Force the port to try and install, even though your ports subsystem is old. This will usually be the best route to take, since whatever changes have taken place since the latest subsystem package and the date on the port are probably not incompatible. If they were incompatible a newer subsystem upgrade package would (should) have been posted. * Wait until a newer subsystem upgrade package is available. * Attempt to upgrade the subsystem yourself. As a minimum, this will involve copying etc/mtree/BSD.x11.dist, usr/share/mk/bsd.port.mk, and usr/share/mk/bsd.port.subdir.mk from FreeBSD-current. It is possible that these are not the only files you need to copy, so please do not try this unless you are willing to fix your own mistakes. Finally, remember that unless you are running FreeBSD-stable, there are no guarantees that every port will work for you! If you are, for example, running FreeBSD-2.1.7 you can expect that many ports will not work, even if you have upgraded your ports subsystem. If you find that a given port does not work on the latest official release of FreeBSD (after upgrading its ports subsystem), you may be entitled to a bug report, but complaints about ports not working on any other release of FreeBSD (including FreeBSD-current) should only be sent if they are accompanied with patches, in which case they are welcomed whole-heartedly!! or whatever. I don't do Linuxdoc, only DocBook. Further, I don't know how to do DocBook, so if that's what you want, you'll be waiting until Christmas, at best. Unless you want only very simple and artificial Linuxdoc. If I say I could do that, I'd discourage volunteers, but I guess I could. ;) I'm a sucker for people who ask really nicely, since all I want is attention. ;-) -- tIM...HOEk OPTIMIZATION: the process of using many one-letter variables names hoping that the resultant code will run faster.