| 1 |
On Thu, Sep 10, 2015 at 8:53 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> |
| 3 |
> So we are breaking consistency and introduce maintenance and |
| 4 |
> configuration complexity, because we want to support a corner case that |
| 5 |
> isn't consistently supported anyway and will not be (because that's what |
| 6 |
> the gnome team said and most upstream maintainers do). |
| 7 |
> |
| 8 |
> You'd actually have to start forking upstream projects if you are |
| 9 |
> serious about this. |
| 10 |
|
| 11 |
Again, I'm saying that maintainers should be free to support multiple |
| 12 |
versions if they wish to do so. They should not be required to do so. |
| 13 |
And yes, I do realize that this limits options for users, but they're |
| 14 |
welcome to proxy-maintain packages that do support the versions they |
| 15 |
wish to use. If they want to fork upstream they're even welcome to do |
| 16 |
that, but obviously that isn't going to happen often. |
| 17 |
|
| 18 |
I just don't think we should be in the business of saying "no" here. |
| 19 |
|
| 20 |
> |
| 21 |
> I think a lot of people just go wild when they see configure switches |
| 22 |
> and stuff everything into USE flags without really considering the |
| 23 |
> impact or the usefulness. |
| 24 |
> |
| 25 |
> It's not all about choice, it's also about sanity. |
| 26 |
> |
| 27 |
|
| 28 |
And again, I'm just saying to leave it up to the maintainer. They can |
| 29 |
decide what is sane and what is not. |
| 30 |
|
| 31 |
That is basically how we do everything around here. I can't really |
| 32 |
think of that many situations where a maintainer wanted to provide |
| 33 |
some kind of configuration and they were forbidden from doing so. |
| 34 |
Now, sometimes we might tell them /how/ to provide that configuration |
| 35 |
so that it is more consistent across the tree, or so that build |
| 36 |
behavior is more deterministic/etc. |
| 37 |
|
| 38 |
> Everything else is just fighting the deprecation, |
| 39 |
> which will come anyway. |
| 40 |
|
| 41 |
Everything we do is fighting deprecation. gtk3 will be deprecated |
| 42 |
someday, most likely, and yet we're doing all this work to roll it |
| 43 |
out. |
| 44 |
|
| 45 |
Maintainers should be free to add value to Gentoo when they feel it is |
| 46 |
worth their time to do so. That is basically how we got to where we |
| 47 |
are today. Gentoo supports all kinds of stuff that I think is |
| 48 |
intellectually interesting but which I'd probably not use personally, |
| 49 |
but I'm happy to see it happening all the same and I'm happy that it |
| 50 |
is scratching somebody's itch. At the same time, I use Gentoo |
| 51 |
features that were added because they scratched somebody else's itch, |
| 52 |
even if they weren't thinking about me personally when they did it. |
| 53 |
|
| 54 |
-- |
| 55 |
Rich |
Archives