On Mon, Aug 23, 2004 at 09:25:10AM -0700, Michael Stenner alleged: > On Sun, Aug 22, 2004 at 11:01:34PM -0700, Garrick Staples wrote: > > On Sun, Aug 22, 2004 at 11:00:42PM -0700, Garrick Staples alleged: > > > > > Similar to apache: > > > > > includepkgorder=includepkg,excludepkg > > > > > or > > > > > includepkgorder=excludepkg,includepkg > > > > > > > > > > First match wins. > > > > > > > > and when it is not listed? > > > > > > > > -sv > > > > > > *shrug* Default to includepkg,excludepkg. > > > > Or make it mandatory. Specifying both options *must* also have an order > > specified. > > I have a severe dislike for unnecessarily mandatory options. People > who have sufficiently complex setups as to BOTH include and exclude > the same package, should probably RTFM anyway. It also adds another > layer of complexity to the the code. I'm just throwing out ideas and "community input" to help resolve Seth's perceived problem with these options. Playing devil's advocate for mandatory options... it would *force* people to RTFM. The natural inclination of most users is to just try the most obvious solution before RTFMing. If you, one of the developers, understands that the user is going to miss vital information and that RTFMing will avoid landing the bullet in his/her foot, then forcing the user here is a good thing. Wider commentary... I think this point's to one of yum's wider problems: lack of focus. I asked once before (a long time ago), if yum was a convienence tool to help out new users or if it was a power tool for advanced admins; the question was never answered. I know what *I* use it for, I know what some other people use it for, and I also know how else I'd *like* to use it. So I ask again, what is yum's intended audience? -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20040823/2dcaf5c7/attachment.bin