Date: Sun, 10 Dec 1995 14:20:42 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: rkw@dataplex.net (Richard Wackerbarth) Cc: hackers@freefall.freebsd.org, jkh@time.cdrom.com, jgreco@brasil.moneng.mei.com Subject: Re: Sup's Freefall-centric tree conventions Message-ID: <199512102220.OAA22820@freefall.freebsd.org> In-Reply-To: Your message of "Sun, 10 Dec 1995 15:41:53 CST." <v0213050facf0ff6dbc24@[199.183.109.242]>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>Justin T. Gibbs writes: > >>>B) One portion of the files describe the user's end, another describe the >>>server. >>>There will be multiple servers. Each of them should (I would say MUST) >>>have the same structure. Joe User should be able to reference anyone of >>>them by simply changing the server address. (Frankly, I would prefer that >>>the server address be set in the first line and automatically remembered >>>until it is changed. That would reduce the customization to a single >>>point.) >> >>The only thing that must be the same on all servers is the location of >>the collection information (/home). > >Not the location that I would choose. Here, remember that we are talking >about servers that are likely to have significant demands to do multiple >things. Fine, decide where you want the collection information on the servers, and I'll change it. I don't care about where hostbase is set to, because it does not affect our endusers. >>SUP is flexible enough to handle either case. >Here, we agree. The argument is about the "correct" default configuration. Yup. >> I'm just trying to handle the default case the best way. There is >>nothing "ego-centric" about the approach at all. > >Yes, there is. It is very ego-centric to think that there is only one >source. That kind of thinking is just what has created the mess that "make >world" is in. By the definition of ego-centric, this policy cannot be ego-centric. The files are not designed for core, me, or you. They are designed to be useful to the largest portion of our SUP user base. >The correct solution is to link your source tree to the library reference >version of the distribution, if that is what you want. ^^^^^^^^^^^^^^^^^^^^^^^^ There are lots of correct solutions depending on what you want. >Sup is a mechanism >to maintain the reference copy. It does not support local modifications >well. To try to use it as if it does leads the unsophisticated to trouble. No one was trying to push SUP for this purpose. For people who want to maintain their own local changes, they should be SUPing the CVS tree! >>>I want to run 2.1-RELEASE, but sup both -stable and -current to decide what >>>changes I wish to integrate into my system. > >This is typical of the "joe user" who should not be editing supfiles. >He should not trash his working source just because he decides to look at a >current version of some source tree. How many of these "joe users" currently use our SUP system? I would say that they are the exception and not the rule. Your definition of a "Joe User" knows enough about the system to extract patches from our source distributions and pull them into their local tree. They should also be intelligent enough to know that running a SUP into /usr/src will clobber /usr/src just like an ftp-mirror into /usr/src would. I still maintain that 99% of our users (those not using CVS) use SUP to update their /usr/src. The changes you request affect this large user base who may not know how to adjust to the change. >> Further, I will be a supserver for others for both -stable and -current. > >However, I admit that this is not. However, maintainance of the supservers >should also be made painless. True each admin has the knowledge to >customize, but remember that he does not want to spend the time to do so. >The "stock" solution needs to "just work". That way, when someone adds >another line to the files, the admin can just use the revised file and be >up-to-date. This is the job of Jordan's supserver package. It should contain modified supfiles that sync with the collections he's distributing. I see this as a totally separate issue. If Jordan wanted to be really slick, there would be a SUP collection for the collections and supfile for suping the collections. :) Then it would be a "setup and forget" solution. >>Why? They are only "example" supfiles, designed to handle the generic case. > >Bad design. "Examples" should be replaced by "defaults" that work. We can't create default files that will satisfy everyone's needs. > >---- >Richard Wackerbarth >rkw@dataplex.net > > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512102220.OAA22820>