On Fri, 2005-04-29 at 09:25 -0400, Dan Meltzer wrote: > The problem with ebuild config, at least until bug 11359 is handled, > is if the package is emerged early on in a list of packages, there is > a chance the person won't know to use ebuild config.... would it be > possible for portage to run an ebuild config for _all_ packages that > need it after _all_ packages that are being emerged are emerged? This > way the upgrade goes without interference, but the customization waits > until the person comes back, either that or an emerge config that > tracks all packages that need config that have yet to be configged, > currently, hoping a person thinks to ebuild packagename config is a > lot to ask, unless every package takes use of it...
My opinion: I really don't care. We aren't doing anything in the config sections that cannot be done manually, we're just making it easier by scripting it into a single place. As more and more packages make use of the mechanism, people will become used to using it. If someone doesn't use it, they won't have a broken package, just an unconfigured one, so there's no harm to any users by them missing the config step. That and we hope that at some point in the future, portage will have a mechanism in place for logging all of the output for later. I wouldn't mind seeing some way to run all the config steps after the ebuilds, but in most cases you would only need to run the config step once, not on every upgrade of the package. > On 4/29/05, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-04-29 at 09:36 +0900, Jason Stubbs wrote: > > > > In fact, I've thought many times about supplying "pre-packages" that are > > > > no more than a collection of all the config files for a given package. > > > > > > What about the unused `ebuild [ebuild] config`? Isn't that the perfect > > > place > > > for this sort of stuff? The only package that I know that uses this > > > feature > > > is mysql. There are way more possibilities. > > > > I use it fairly regularly. I know that we use it on any game that > > requires a CD key, and also for VMWare (I bet most people don't know > > that!) to configure the modules. > > > > I hadn't considered using it for actually configuring a package (duh!) > > but that really is a very cool idea. Imagine if we started doing this > > for more packages. It would remove one of the primary complaints people > > have about Gentoo being "too hard" since they don't know "what to do > > next" after they emerge a package. If we got people used to "ebuild > > [ebuild] config", then we could remove a good bit of the issue. > > > > Just an idea, but one I'll probably be using more often now. > > > > -- > > Chris Gianelloni > > Release Engineering - Strategic Lead/QA Manager > > Games - Developer > > Gentoo Linux > > > > > > > -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
