| 1 |
On Sunday 02 October 2005 01:08, Daniel Stiefelmaier wrote: |
| 2 |
> On Saturday 01 October 2005 14:17, Jason Stubbs wrote: |
| 3 |
> >This should go to gentoo-dev@g.o as ebuild developers are the ones that |
| 4 |
> > decide what USE flags are available and how they're documented. |
| 5 |
> |
| 6 |
> Of course they decide what flags are available, but how do they decide |
| 7 |
> how they are documented? I'm sorry if i did not yet discover gentoos |
| 8 |
> ebuild-feature-documentation system. |
| 9 |
|
| 10 |
I meant the actual strings themselves. However, any change that affects or |
| 11 |
enables work for ebuild devs really needs to be discussed with them. |
| 12 |
|
| 13 |
> I thought of a command like emerge mozilla-firefox --useinfo |
| 14 |
> that prints what each flag is good for. Maybe some are explained in 5 |
| 15 |
> words, other may need 5 lines. |
| 16 |
|
| 17 |
Personally, I think that this has only become necessary because USE flags are |
| 18 |
overloaded too much and usually encompass an unintuitive set of |
| 19 |
functionality. In other words, I think the flaw is with the USE flags that |
| 20 |
have been created rather than the USE system itself. |
| 21 |
|
| 22 |
Take the USE flag "perl", for example. It has the description "Adds |
| 23 |
support/bindings for the Perl language." but for mysql setting it enables the |
| 24 |
installation of some support scripts that just happen to be written in perl. |
| 25 |
|
| 26 |
I'd be much more inclined to push for making the USE flags themselves more |
| 27 |
intuitive rather than adding another layer of documentation to exlain the |
| 28 |
unintuitiveness (which would likely be poorly written anyway). |
| 29 |
|
| 30 |
> >>also, the advanced could provide |
| 31 |
> >>- links to howto's (like configuring apache) |
| 32 |
> > |
| 33 |
> >This is out of the domain of a package in any package management system |
| 34 |
> > IMO. |
| 35 |
> |
| 36 |
> You are right, there may be no pms out there that has this feature. |
| 37 |
> I refuse to accept this as an argument to not change that. |
| 38 |
> You may be a pro who does not need any HOWTOs, i am not. |
| 39 |
|
| 40 |
HOWTOs can usually be found by navigating from the package's home page. |
| 41 |
If not, a quick google will find any that exist. |
| 42 |
|
| 43 |
> Portage saves a lot of work for people who use it. But in some cases, |
| 44 |
> ebuilds don't do everything they could or should. |
| 45 |
|
| 46 |
If ebuilds aren't doing what they could or should be, you can open specific |
| 47 |
bugs regarding those packages. |
| 48 |
|
| 49 |
> BTW, if "This is out of the domain of a package in any package |
| 50 |
> management system", then why do some packages print additional |
| 51 |
> information after emerging, like what files should be updated manually? |
| 52 |
|
| 53 |
Usually it's because configuration file layout differs from upstream's |
| 54 |
defaults or some other Gentoo-specific information. |
| 55 |
|
| 56 |
> THIS is not really the solution. if you batch-emerge or the package that |
| 57 |
> wants to tell you something is just a dependancy, then you may probably |
| 58 |
> miss that note. |
| 59 |
|
| 60 |
http://bugs.gentoo.org/show_bug.cgi?id=11359 |
| 61 |
|
| 62 |
> Another reason to inform the user before emerging maybe this: |
| 63 |
> I emerged a package recently, think it was amule, that first emerged |
| 64 |
> some dependancies, including wxGTK. |
| 65 |
> Then, after all dependancies were emerged, the package itself quitted |
| 66 |
> saying that wxGTK needs to be emerged with flag wxgtk1. |
| 67 |
> I thought the ebuild could manage flags of dependancies automatically, |
| 68 |
> but that is not the point. |
| 69 |
> The user could be informed before starting to emerge. |
| 70 |
|
| 71 |
http://bugs.gentoo.org/show_bug.cgi?id=2272 |
| 72 |
|
| 73 |
> >>- list packages that are of use for this (plugins or utilized apps like |
| 74 |
> >>cervisia that integrates in quanta plus) |
| 75 |
> > |
| 76 |
> >Do you mean finding packages that depend on that package in question? |
| 77 |
> |
| 78 |
> Not necessarily. Cervisia, Kompare and Tidy are standalone applications, |
| 79 |
> but Quanta integrates them automatically if they are installed. |
| 80 |
|
| 81 |
A "related" field? Could be useful. This is also a point for discussion on |
| 82 |
gentoo-dev@g.o though. |
| 83 |
|
| 84 |
> >Personally, I hate most wikis. 9 times out of 10, they are full of |
| 85 |
> >half-correct information. This makes them all the more dangerous as the |
| 86 |
> >"average Joe" can't tell what's correct and what isn't. |
| 87 |
> |
| 88 |
> My wiki experiences are all good, but i also wrote, that it could only |
| 89 |
> be maintained by the developers. Only the discussion page attached to |
| 90 |
> each page is open for comments. This also prevents defacements. |
| 91 |
|
| 92 |
More work for ebuild devs, then. Guess where this discussion should be? ;) |
| 93 |
|
| 94 |
-- |
| 95 |
Jason Stubbs |
| 96 |
-- |
| 97 |
gentoo-portage-dev@g.o mailing list |
Archives