| 1 |
On 11/07/2016 00:06, Philip Webb wrote: |
| 2 |
> The proliferation of pkgs in KDE, Gnome, Perl + other areas |
| 3 |
> is going to become a problem for Gentoo, |
| 4 |
> as they will tend to demand more dev attention |
| 5 |
> & will also add to users' burden in keeping track of what they use + need. |
| 6 |
|
| 7 |
I disagree. My burden is maintaining KDE is about the same through major |
| 8 |
versions 3, 4 and 5. Nowadays I mostly list the 30 or so KDE apps I |
| 9 |
actually use in a set, and the USE flags for stuff I have and can use go |
| 10 |
in make.conf. The ebuilds then take care of things and mostly get it |
| 11 |
right. When I say "mostly", I really mean a big percentage with lots of |
| 12 |
9's in it[1] |
| 13 |
|
| 14 |
It's important to realise that these new packages are not new software, |
| 15 |
they are existing software broken up into smaller more atomic chunks. |
| 16 |
|
| 17 |
Example, in KDE-3 we had packages kde, and kde-*-meta. These were no |
| 18 |
atomic, they were "bunches of stuff sort-of somewhat related" like |
| 19 |
games, network and so on. When you break that up into lots of small |
| 20 |
packages, the burden goes *down*, in much the same way that software |
| 21 |
becomes easier when you refactor a giant main() with many global vars |
| 22 |
into many small self contained functions. |
| 23 |
|
| 24 |
I have many times observed comments on -dev where kde maintainers bitch |
| 25 |
loudly about how difficult it is to maintain the large monolithic kde |
| 26 |
packages of versions <5. All this seems to add up to the opposite of |
| 27 |
what you are claiming. |
| 28 |
|
| 29 |
Alan |
| 30 |
|
| 31 |
[1] Be careful not to commit the human problem of remembering the few |
| 32 |
times the ebuild got it wrong (especially when using ~arch), and not |
| 33 |
remembering, or not seeing at all, the many many many times it didn't |
Archives