On Sunday 02 October 2005 01:08, Daniel Stiefelmaier wrote: > On Saturday 01 October 2005 14:17, Jason Stubbs wrote: > >This should go to [EMAIL PROTECTED] as ebuild developers are the ones that > > decide what USE flags are available and how they're documented. > > Of course they decide what flags are available, but how do they decide > how they are documented? I'm sorry if i did not yet discover gentoos > ebuild-feature-documentation system.
I meant the actual strings themselves. However, any change that affects or enables work for ebuild devs really needs to be discussed with them. > I thought of a command like emerge mozilla-firefox --useinfo > that prints what each flag is good for. Maybe some are explained in 5 > words, other may need 5 lines. Personally, I think that this has only become necessary because USE flags are overloaded too much and usually encompass an unintuitive set of functionality. In other words, I think the flaw is with the USE flags that have been created rather than the USE system itself. Take the USE flag "perl", for example. It has the description "Adds support/bindings for the Perl language." but for mysql setting it enables the installation of some support scripts that just happen to be written in perl. I'd be much more inclined to push for making the USE flags themselves more intuitive rather than adding another layer of documentation to exlain the unintuitiveness (which would likely be poorly written anyway). > >>also, the advanced could provide > >>- links to howto's (like configuring apache) > > > >This is out of the domain of a package in any package management system > > IMO. > > You are right, there may be no pms out there that has this feature. > I refuse to accept this as an argument to not change that. > You may be a pro who does not need any HOWTOs, i am not. HOWTOs can usually be found by navigating from the package's home page. If not, a quick google will find any that exist. > Portage saves a lot of work for people who use it. But in some cases, > ebuilds don't do everything they could or should. If ebuilds aren't doing what they could or should be, you can open specific bugs regarding those packages. > BTW, if "This is out of the domain of a package in any package > management system", then why do some packages print additional > information after emerging, like what files should be updated manually? Usually it's because configuration file layout differs from upstream's defaults or some other Gentoo-specific information. > THIS is not really the solution. if you batch-emerge or the package that > wants to tell you something is just a dependancy, then you may probably > miss that note. http://bugs.gentoo.org/show_bug.cgi?id=11359 > Another reason to inform the user before emerging maybe this: > I emerged a package recently, think it was amule, that first emerged > some dependancies, including wxGTK. > Then, after all dependancies were emerged, the package itself quitted > saying that wxGTK needs to be emerged with flag wxgtk1. > I thought the ebuild could manage flags of dependancies automatically, > but that is not the point. > The user could be informed before starting to emerge. http://bugs.gentoo.org/show_bug.cgi?id=2272 > >>- list packages that are of use for this (plugins or utilized apps like > >>cervisia that integrates in quanta plus) > > > >Do you mean finding packages that depend on that package in question? > > Not necessarily. Cervisia, Kompare and Tidy are standalone applications, > but Quanta integrates them automatically if they are installed. A "related" field? Could be useful. This is also a point for discussion on [EMAIL PROTECTED] though. > >Personally, I hate most wikis. 9 times out of 10, they are full of > >half-correct information. This makes them all the more dangerous as the > >"average Joe" can't tell what's correct and what isn't. > > My wiki experiences are all good, but i also wrote, that it could only > be maintained by the developers. Only the discussion page attached to > each page is open for comments. This also prevents defacements. More work for ebuild devs, then. Guess where this discussion should be? ;) -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
