From owner-freebsd-stable Mon Apr 9 22:56:10 2001 Delivered-To: freebsd-stable@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id F17B737B422 for ; Mon, 9 Apr 2001 22:55:59 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id AAA03087; Tue, 10 Apr 2001 00:55:53 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-88.tnt1.rac.cyberlynk.net(209.224.182.88) by peak.mountin.net via smap (V1.3) id sma003042; Tue Apr 10 00:55:15 2001 Message-Id: <4.3.2.20010409225422.0271d820@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 10 Apr 2001 00:54:00 -0500 To: "Matthew Emmerton" , "Conrad Sabatier" , "Bob K" From: "Jeffrey J. Mountin" Subject: Re: supfile idea (was Re: Releases) Cc: In-Reply-To: <008901c0c162$8a684960$1200a8c0@gsicomp.on.ca> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_605628960==_" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=====================_605628960==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:04 PM 4/9/01 -0400, Matthew Emmerton wrote: >I like the idea of stable-supfile, so it should stay. standard-supfile >should *definitely* refer to the -REL in which it is a part of. In that >case, a novice user who doesn't change anything would end up cvsup'ing code >that they already have on their system or on CD - no harm done. Further, >they'd actually have to RTFM to figure out what tags to use to get what they >really want. Another issue that is common here and wonder if you are aware of this file: /usr/src/share/examples/cvsup/README Frankly I think there should be the readme and *ONE* example. There is a lot of duplication and since most use only one cvsupfile, possibly less confusion. I see there is a disclaimer for adding the ports collection in the "standard" version. Use that as a base and these: ports-supfile stable-supfile standard-supfile www-supfile Can be rolled into one, call it "new-supfile" for now, and now there are only: README cvs-supfile gnats-supfile new-supfile refuse refuse.README Less choices and changing "new" to "standard" should make it the obvious choice and not require building up a typical supfile. Not sure that the gnats could be folded in, as it uses "release=current" rather than "release=cvs" and does not use a "tag=" and having one might throw it off (John? anyone?). Also might not be a good idea to fold it in, since only those that work on PR's might want a local copy. Another common issue is when using individual collection vs src-all. Many time a person has src-crypto and no src-secure. Or worse, someone points out only one of them is missing and neglects to mention the other. It would be difficult to say what is optional, but if you consider /etc/defaults/make.conf *and* lose the comments before the crypto collections (outdated, but might be necessary in the future) then something like: # required by default #src-base #src-bin #src-contrib #src-etc #src-games #src-gnu #src-include #src-lib #src-libexec #src-sbin #src-share #src-sys #src-usrbin #src-usrsbin #src-crypto #src-secure #src-sys-crypto # optional #src-kerberos5 #src-kerberosIV #src-release #src-tools #src-eBones And perhaps a quick reference to make.conf and a suggestion to pull in src-release even if one doesn't wish to roll their own for the text files that everyone tracking stable *should* know about. Perhaps a quick reference to the handbook or FAQ to avoid cluttering the file like this. # comment the following if "NOGAMES=yes" in make.conf #src-games # un-comment the following if "MAKE_KERBEROS5=yes" in make.conf etc... The idea is to make it simple, central, and with simple comments that should avoid the common mistakes. And yes, I am aware that removing the supfiles for ports, doc, www, and stable would require a change to make.conf. They could remain and the standard might be updated to an all-in-one supfile rather than for -current. Perhaps all that is needed is a comment in the README to refer to the handbook for those new to fetching the source and what should be used when using individual collections. Minimal clutter and hopefully get more to RTFM before diving in. Mind right now I'm not sure where the docs are and how satisfactory they are (no insult to the docs people). Was going to update them, but find the docproj has bloated quite a bit in recent history. Might want to warn those fetching doc-all what it will take to build that beast. 8-) Can Kris or someone else say if src-sys-crypto is required or not. There was a discussion on this a long time back, but recall the answer was fuzzy and it *might* be required in the future for in-kernel crypto. I do list it when suggesting a trimmed down list rather than src-all. It's small and safer to do so. Rather than reply to another will agree with Donn that "standard" should be "current" to avoid confusion. Then making "standard" an all inclusive (or should I say "mostly") example might be a good idea along with pointing to documentation. Of course getting users to read things is always an issue. All the documentation in the world won't stop a (l)user from getting a bad case of LLMF. My question at this point is before changing a thing it would be best to find out how most get lost and then work out a remedy, which I could have stated in the first place and had less fun trying to cover a number of possibilities. It would be nice to force a new user to a certain minimum of RTFM, but might leave some cold and certainly won't stop them from not doing so, screwing up, and asking "why?" Attaching a copy of my idea of what standard-supfile should be like. --=====================_605628960==_ Content-Type: application/octet-stream; name="standard-supfile-new" Content-Transfer-Encoding: x-uuencode Content-Disposition: attachment; filename="standard-supfile-new" begin 600 standard-supfile-new M(R`D1G)E94)31#H@6]U7-T M96T@96%S:6QY"B,@86YD(&5F9FEC:65N=&QY("AF87(@;6]R92!S;R!T:&%N M('=I=&@@2!S97)V97(L M('EO=2!S:&]U;&0@2!W:7-H('1O(&-H86YG92!S;VUE(&]F('1H92!S971T:6YG M6]U(&%R92!#5E-U<'!I;F<@82!L87)G92!N=6UB97(@;V8* M(PD)8V]L;&5C=&EO;G,L('EO=2!W:6QL(&)E(&AA2!M=7-T(&5X:7-T(&EN(&]R9&5R('1O(')U;B!#5E-U<"X*(PHC(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C"@HC($1E9F%U;'1S('1H M870@87!P;'D@=&\@86QL('1H92!C;VQL96-T:6]N'0@;&EN92!T;R!U#TO=7-R"B,@5&AE(&9O;&QO=VEN9R!L:6YE(&ES(&9O6]U('=A;G0@=&\@=')A8VL@+5-404),12P@;&5A=F4@=&AI7,* M(W-R8RUT;V]L7!T;PH*(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(PHC"B,@1$%.1T52(2`@5T%23DE.1R$@($Q/3TL@3U54(2`@5D]24TE#2%0A M"B,*(R!4:&4@9F]L;&]W:6YG(&-O;&QE8W1I;VYS(&%R92!C;VUM;VX@=&\@ M86QL(&)R86YC:&5S+@HC(`HC(%1H:7,@;&EN92!-55-4(&)E('5N8V]M;65N M=&5D('=H96X@=7-I;F<@86YY(&]F('1H90HC(&-O;&QE8W1I;VYS(&)E>6]N M9"!T:&ES('!O:6YT('5N;&5S6]U('5S92!A;GD@ M;V8@=&AE"B,@;W1H97(@:6YD:79I9'5A;"!C;VQL96-T:6]N6]U2!I9B!I=`HC(&ES(&YO="!K97!T('5P('1O(&1A=&4N M"B-P;W)T0HC M<&]R=',M8V%D"B-P;W)T7-U=&EL#$Q M"B-P;W)T#$Q+7=M"@HC(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(R,C"B,@"B,@3F]N+6-O9&4@8V]L;&5C=&EO;G,*(R`*(R,C(R,C(R,C(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(PH*(R!4:&ES('=I;&P@0HC=W=W"@`` ` end --=====================_605628960==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve --=====================_605628960==_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message