-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 02 November 2003 05:33 pm, Dhruba Bandopadhyay wrote: > ** > Initially, sent to gentoo-dev but later sent also to gentoo-user for > feedback. **
It seems like you got a good idea, and decided to come up with a ton of ideas that are unnecessary and are already built into the system. <snip> > -------------------------------- > Scenario 1: slocate and updatedb > -------------------------------- > 1) Remove slocate from base system > 2) Remove makewhatis from daily cron duties > 3) Remove updatedb from daily cron duties I never use this stuff either. Unmerge it and mask it. Problem solved. > ------------------------------------- > Scenario 2: baselayout and /etc/issue > ------------------------------------- > 1) Eliminate /etc/issue and rename it if it must be added to the system What's your issue with /etc/issue? IIRC, it's the MOTD so if you change it, it won't get overwritten (unless YOU do so with etc-update). > --------------------------------------------------- > Scenario 3: vanilla kernels and development sources > --------------------------------------------------- > 1) Provide the kernel in vanilla fashion without customisations > 2) Reconsider using the alsa and vanilla use flags here as they violates > the rule of using use flags only for compile time switches. Ummm. Emerge vanilla-kernel? Stock - no patches. No IUSE or USE. It downloads, unpacks. That's it. As to number 2 - there is no rule set in stone enough not to be broken. The kernel sources are a good example of an area where there are a lot of different patches that could be added or removed based on what you have/want/ need. By "hardwiring them" you create an even worse "problem" then the one you try to fix with next scenario - a different kernel for every imaginable situation. Also, development-sources is vanilla. Check the ebuild. > ------------------------------------- > scenario 4: kernel sources on portage > ------------------------------------- > 1) Create gentoo patchsets only for finished releases and separate into > different sources > 2) Provide vanilla kernels as unaltered, unpatched and uncustomised sources > just as they would be if done manually > 3) Agree on prerequisites that must be fulfilled prior to adding new > kernels-sources or in fact any new packages onto portage. Vanilla sources are unaltered - for the most part. If they are not "generic" enough for you, download and install it from kernel.org. Problem solved. I like the choices in kernel! Just ignore the rest if you don't like them. The install guide tells the newbie installer how to get through it. Besides, according to a recent thread on gentoo-dev, some of the kernel-sources are going away due to lack of maintainers. So, there you go. > ------------------------- > Scenario 5: Ebuild speech > ------------------------- > 1) Eliminate all use of sleep in ebuilds > 2) Eliminate all use of beeps via echo -ne "\a" > 3) Write eclasses or modifications to portage which control logging and > display - I have even written a bash wrapper (unfinished) around emerge > which does log all output and displays all messages at end of every emerge > separated according to package names. > 4) If there absolutely has to be sound it must be done through > FEATURES="sound". FEATURES="notify" can be used for message waits if > absolutely necessary. It's a shame that finally EULA's have made ebuilds > interactive and sound and message waits are further increasing merge time Not a bad idea at all - in fact, the first one so far that I think would be a great FEATURE - silence. But you don't have to wait for EULA interactivity - and AFAIK it's only on two different ebuilds. Add an ACCEPT_LICENSES line to make.conf - add all the licenses you wish to accept and ebuilds won't stop on license agreements anymore. Check the ebuild (like enemyterritory) for the License Type.... > Overall, I would say vanilla behaviour should always be exhibited by > default in all aspects of the operating system in favour of user preference > or dev preference. 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. Exceptions are where the change is vanilla in itself like providing > stock kernel configs to newbie users as genkernel does. Why? This is not a vanilla system - it is a Gentoo System. I expect that the gentoo dev's will make enough modifications to the vanilla to work as expected with the other parts of the Gentoo System. Certain amounts of vanilla-ness are fine, but I would hope the devs would continue to patch the ebuilds and make them work correctly on my system. Do you think that Debian is vanilla? Can you name to me even ONE vanilla distro? LFS - perhaps - but even that will lose "vanilla-ness" as you make modifications. As I mentioned before, these are issues you can take care of on your own system without modifying everything for everyone. Modify the ebuilds yourself to remove patches.. It's not that hard - then put them in your portdir overlay path and hard mask them in place. Cheers, - -- Matt http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D81740A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/poP/ZosHVX2BdAoRAm/wAJ9DR/WAyBpmRDo8LdhYKd5neox1hgCff29w w3R0EmxNAEESgyFSTXonTss= =rg93 -----END PGP SIGNATURE----- -- [EMAIL PROTECTED] mailing list
