| 1 |
On Thu, Feb 2, 2017 at 10:59 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> |
| 3 |
> The upstream defaults would |
| 4 |
> build on top of the minimal base profile, in plain old package.use. In |
| 5 |
> the profile is exactly where the upstream defaults belong in an |
| 6 |
> "upstream defaults" profile. |
| 7 |
> |
| 8 |
> I think (base == minimal) is the simpler way to allow both possibilities. |
| 9 |
> |
| 10 |
|
| 11 |
Which is simpler, a minimal profile that sets USE=-* and then lists a |
| 12 |
few exceptions where that breaks in package.use, or an upstream |
| 13 |
defaults profile (which becomes the basis for all the other profiles) |
| 14 |
that has a 5000 line package.use file that specifies the upstream |
| 15 |
defaults for every package in the repository? |
| 16 |
|
| 17 |
Profiles like desktop/server/etc seem far more likely to end up being |
| 18 |
based on the upstream defaults profile than on the minimal profile, so |
| 19 |
calling the minimal profile "base" also seems a bit wrong. |
| 20 |
|
| 21 |
It just seems easier to start with an elegantly created set of |
| 22 |
reasonable defaults and apply a sledgehammer to it, than start with a |
| 23 |
barren wasteland and then try to carefully create a lot of detail on |
| 24 |
top. |
| 25 |
|
| 26 |
Also, as has been pointed out in the other subthread, a lot of this |
| 27 |
stuff becomes use-case-specific. I get that people don't want stuff |
| 28 |
they don't want, but it often isn't actually based on whether they're |
| 29 |
running desktop vs server or embedded vs traditional and so on (which |
| 30 |
is also the issue with server profiles in general). If you want to go |
| 31 |
down that road I think mix-ins make far more sense so that you can |
| 32 |
have a million very-specific use cases addressed with specific |
| 33 |
solutions rather than having everybody arguing endlessly about whether |
| 34 |
a "server" needs imagemagick or apache. |
| 35 |
|
| 36 |
-- |
| 37 |
Rich |
Archives