From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2039 invoked by uid 1002); 3 Nov 2003 09:35:28 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 17857 invoked from network); 3 Nov 2003 09:35:27 -0000 Date: Mon, 3 Nov 2003 01:39:04 -0800 From: "Robin H. Johnson" To: gentoo-dev@gentoo.org Message-ID: <20031103093904.GB8270@curie-int.orbis-terrarum.net> Mail-Followup-To: gentoo-dev@gentoo.org References: <3FA5AF6F.5030501@codewordt.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <3FA5AF6F.5030501@codewordt.co.uk> User-Agent: Mutt/1.5.4i Subject: Re: [gentoo-dev] Vanilla behaviour in Gentoo Linux (long email) X-Archives-Salt: 315242e1-3d33-43ed-9ff1-6c0aad38eaa5 X-Archives-Hash: ecc672c27ddad80f706e6a71948d93a7 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2003 at 01:29:19AM +0000, Dhruba Bandopadhyay wrote: > -------------------------------- > Scenario 1: slocate and updatedb > -------------------------------- [snip] > 1) Remove slocate from base system > 2) Remove makewhatis from daily cron duties > 3) Remove updatedb from daily cron duties Items 2 and 3 above are easily accomplished with=20 chmod -x /etc/cron.daily/{makewhatis.cron,slocate} That's all that's needed. > I'm probably not alone in the fact that I never use slocate and given fix= ed=20 > location of package files and other files in gentoo finding things is=20 > easier than other distros especially given qpkg -l and etcat -f. The big issue at hand isn't pleasing just you, but finding the best common ground for all Gentoo users. Based on what I know of UNIX users, I'd say more often than not they want and use the the locate command (which is provided by slocate). You note that you are interested in the enforcement of 'expected vanilla behaviors' of the operating system. Vanilla is defined as: "Lacking adornments or special features; basic or ordinary" (Dictionary.com) > Overall, I would say vanilla behaviour should always be exhibited by=20 > default in all aspects of the operating system in favour of user preferen= ce=20 > or dev preference.=20 I haven't seen a single UNIX other there (apart from LFS and it's kin) where some form of regularly running updatedb/makewhatis isn't present by default.=20 Therefore, it logically follows that it is ordinary and vanilla to have slocate and makewhatis in place. I will concede one point with regard to them, running them as 'niced' as possible is probably a worthwhile change to make so that they don't hit our systems so hard. Consider also tweaking what time the daily cronjobs etc. run, so that they take place at a time your computer is up and running, but you aren't actively using it. > ------------------------------------- > Scenario 2: baselayout and /etc/issue > ------------------------------------- [snip] Again, see my comments about what is vanilla. > My requests: > 1) Eliminate /etc/issue and rename it if it must be added to the system Somewhere, I recall seeing a package that required /etc/issue to exist, as it caused problems otherwise. > --------------------------------------------------- > Scenario 3: vanilla kernels and development sources > --------------------------------------------------- > ------------------------------------- > scenario 4: kernel sources on portage > ------------------------------------- [snip] I'm not going to argue about kernel stuff, other than to say that there should be an absolute minimal amount of modification compared to how each set of sources ship. Please note that is not only vanilla sources, but rather all sources in the tree.=20 > 1) Create gentoo patchsets only for finished releases and separate into= =20 > different sources In the case of the custom gentoo kernels, they are shipping with plenty of customizations of their own, because they intend to have them. > 2) Provide vanilla kernels as unaltered, unpatched and uncustomised sourc= es=20 > just as they would be if done manually Acceptable changes should be fixes of major breakages and compilation fixes specific to the Gentoo system. GCC3.3 string fixes for a major exampl= e. > 3) Agree on prerequisites that must be fulfilled prior to adding new=20 > kernels-sources or in fact any new packages onto portage. Define pre-requisites in this case. I'd say any commonly used and expected kernel for all architectures that Gentoo supports and is in the process of trying to support belong in the tree. > ------------------------- > Scenario 5: Ebuild speech > ------------------------- [snip] The beeps and waiting are there for a specific reason, in that sometimes there are very important messages that WILL break a users system unless they do some additional instruction that is specified. We generally try very hard to avoid this, but there are some cases where it cannot be avoided.=20 For an example, I'm currently writing up some ebuilds for the new 5.3 tree of vpopmail, because it will be released from it's upstream beta state soon. The upgrade path involved in this, if I were to have a script to do it automatically, would entail forcing the user to stop courier-imap+qmail, run the emerge upgrade, run a command to migrate their data, and recompile courier-imap, and restart qmail+courier-imap. So now, how to go about this and NOT break the system of the user that runs 'emerge -u world' and goes to bed? There is no simple solution for this. > Focus should be on instructing the user on how to make a change rather > than making the change and expecting the user to reverse it.=20 The big problem is quite simply that users don't read the big warnings and information as it stands already. The beeps and sleeping at least get a fair number of users to read the messages and find out what to do. However I still get a significent number of bugs filed just because users fail to read the instructions that have been provided. One that keeps getting filed as a bug with some regularity is the mysql configuration instructions to create the database and set the initial passwords. Absolutely essential for the application to work, and completely documented in the pkg_postinst of the package telling you to run the ebuild ... config command. Yet I still get several bugs a month for this, because users failed to read the instructions that we provided. If there were a solution that could resolve the issues you have with the delays and waiting, while still getting more of the users to READ the instructions that are already provided, I'd be incredibly grateful as it would reduce the amount of time I spend on non-productive bugs. For each of the bugs that gets filed presently like this, I try as hard as I can to ensure that the user understands the problem and is explictly shown how to resolve it. > 3) Write eclasses or modifications to portage which control logging and= =20 > display - I have even written a bash wrapper (unfinished) around emerge= =20 > which does log all output and displays all messages at end of every emerg= e=20 > separated according to package names. Logging is already done, see PORT_LOGDIR in make.conf. If you really need to find the messages afterwards, just grep in the newly produced logfiles as you do above. > 1) Eliminate all use of sleep in ebuilds > 2) Eliminate all use of beeps via echo -ne "\a" > 4) If there absolutely has to be sound it must be done through=20 > FEATURES=3D"sound". FEATURES=3D"notify" can be used for message waits if= =20 > absolutely necessary. It's a shame that finally EULA's have made ebuilds= =20 > interactive and sound and message waits are further increasing merge time No arguments with this in principle. Lets have FEATURES=3D"sound" and FEATURES=3D"wait", both enabled by default. --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQE/piI4snuUTjSIToURAh1eAKC0R8Ykx20imsEbGyS9pFOTPYMaaACglOQl BWjSQKLWglyd78cusiY5hjI= =QOz9 -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7--