| 1 |
Maciej Mrozowski <reavertm@×××××.com> writes: |
| 2 |
> And I fail to see *any* point in forcing users to learn Gentoo internals (sic! |
| 3 |
> like USE flags). What else? Ebuild syntax so that they're able to get to know |
| 4 |
> what particular global USE flag is responsible for, when someone forgot (or |
| 5 |
> decided not to) describe it in metadata.xml even when semantics is different? |
| 6 |
> Maybe I sound too harsh here, but that's because I'm not ideologist - I'm |
| 7 |
> practical man. |
| 8 |
|
| 9 |
If the point of the distribution is – like some other distros – to have |
| 10 |
a high-functioning, high-polish, well-integrated system and desktop with |
| 11 |
a minimal amount of end-user knowledge, then, yes, the goal should be |
| 12 |
for end-users to not need to know about such things. |
| 13 |
|
| 14 |
But profiles, make.conf, USE flags (especially!), elog, &c. … these |
| 15 |
things are not "internals", but instead the interface the package |
| 16 |
manager presents to its user. They are the "language" the user is |
| 17 |
expected to speak in to interact with her system. The trade off for |
| 18 |
doing this is more and finer-grained control over the system, and the |
| 19 |
reason people choose Gentoo. Even ebuilds themselves are (usually) |
| 20 |
sufficiently non-magical that I think they could qualify in some |
| 21 |
circumstances, though that quickly starts to get into eclasses, PM |
| 22 |
behavior and real "internals". |
| 23 |
|
| 24 |
-- |
| 25 |
...jsled |
| 26 |
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b} |
Archives