| 1 |
> |
| 2 |
> Categories themselves were not a design mistake. The design mistake is |
| 3 |
> using categories to permit conflicting package names. |
| 4 |
> |
| 5 |
> Categories are convenient. Sure, they're not perfect but they serve |
| 6 |
> their purpose to some degree and there's little harm in having them. |
| 7 |
> If you want to organize packages better, nobody's stopping you. Until |
| 8 |
> you've got a better and widespread replacement, I don't see why people |
| 9 |
> shouldn't be using categories as they see fit. |
| 10 |
> |
| 11 |
> The other part is something we could aim for fixing but so far most |
| 12 |
> developers seems to disagree with me, so there's no point in pursuing |
| 13 |
> that. |
| 14 |
> |
| 15 |
|
| 16 |
So how about improving categories instead? |
| 17 |
|
| 18 |
Rough idea: |
| 19 |
* introduce 1st, 2nd, 3rd class categories, categorized in metadata somewhere |
| 20 |
* 1st class is what you want in your world file (and default setting) |
| 21 |
* 2nd class is everything else |
| 22 |
* 3rd class is stuff that should never be in your world file (but still can be, if you want) |
| 23 |
|
| 24 |
Then tooling can (maybe output a warning but) default to highest class category if none is given. |
| 25 |
|
| 26 |
Examples: |
| 27 |
* 1st class: app-*, dev-lang, games-*, ... |
| 28 |
* 2nd class: dev-haskell, dev-perl, dev-php, dev-python, dev-texlive, media-libs, net-libs, sci-libs, ... |
| 29 |
* 3rd class: acct-*, perl-core, virtual |
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
Andreas K. Hüttel |
| 34 |
dilfridge@g.o |
| 35 |
Gentoo Linux developer |
| 36 |
(council, toolchain, base-system, perl, libreoffice) |
Archives