Date: Thu, 30 May 1996 14:34:14 +0100 (BST) From: Paul Richards <p.richards@elsevier.co.uk> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: asami@freebsd.org, ports@freebsd.org Subject: Re: Request for feedback: REQUIRES_OS_VERSION feature. Message-ID: <199605301334.OAA00366@cadair.elsevier.co.uk> In-Reply-To: <16316.833412688@time.cdrom.com> from "Jordan K. Hubbard" at May 29, 96 04:31:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Jordan K. Hubbard who said > > The changes add the abstraction of a "check" target which, if it > "breaks the link" between build an configure process, essentially > short-circuits the fetch/extract/build cycle of the port. The default > check target can get as clever as we like as time goes on, but for now > it does no more than check for a variable called REQUIRES_OS_VERSION. > > If this variable is set in a Makefile, the output of `uname -r' will > be compared against it and, if no match occurs, refuse to build > the port. For example, the top port could have: > > REQUIRES_OS_VERSION= 2.2 > > For all variants and 2.1 users could make from the -current tree with > impugnity, any ports like top simply getting skipped. > > Anyway, let me know what you think.. > > Jordan Hmmm, the basic idea of stamping ports is good but I can see a lot of problems with this implementation. How can you mark a port as working with *many* OS versions rather than just the one. If you stamp something as requiring 2.2 then it will probably work with 2.3 and later but will never work with 2.1, which people may still have around for some time (as our releases get more stable and featureful people will tend to leave stable boxes alone). You'd have to change the string at each release to ensure it worked in -current and that would then break older releases. Hmm, I think "feature tags" are the only way to deal with this. Instead of a REQUIRES_OS_VERSION string you have REQUIRES_2_2_VM etc and then somewhere in the system you'd need a file that held these tags if they apply to that version of the OS. i.e. a /usr/share/features file in 2.2 will have a HAS_2_2_VM tag in it. When we move to 2.3, that feature would still be present so you wouldn't have to change anything. It needs some extra work to implement a script to check the tags but it's more flexible and would be less work in the long run since you wouldn't have to change all the ports configuration's at each release. You could really snazzy and assosciate a string with each tag so if the tags missing you get a sensible error message explaining what feature the port requires. It would be trivial to do in perl. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605301334.OAA00366>