| 1 |
On Thu, Sep 10, 2015 at 8:35 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
|
| 3 |
> On 09/10/2015 03:10 PM, Rich Freeman wrote: |
| 4 |
> > On Thu, Sep 10, 2015 at 8:53 AM, hasufell <hasufell@g.o> wrote: |
| 5 |
> >> |
| 6 |
> >> So we are breaking consistency and introduce maintenance and |
| 7 |
> >> configuration complexity, because we want to support a corner case that |
| 8 |
> >> isn't consistently supported anyway and will not be (because that's what |
| 9 |
> >> the gnome team said and most upstream maintainers do). |
| 10 |
> >> |
| 11 |
> >> You'd actually have to start forking upstream projects if you are |
| 12 |
> >> serious about this. |
| 13 |
> > |
| 14 |
> > Again, I'm saying that maintainers should be free to support multiple |
| 15 |
> > versions if they wish to do so. They should not be required to do so. |
| 16 |
> > And yes, I do realize that this limits options for users, but they're |
| 17 |
> > welcome to proxy-maintain packages that do support the versions they |
| 18 |
> > wish to use. If they want to fork upstream they're even welcome to do |
| 19 |
> > that, but obviously that isn't going to happen often. |
| 20 |
> > |
| 21 |
> > I just don't think we should be in the business of saying "no" here. |
| 22 |
> |
| 23 |
> Again, your proposed use case is |
| 24 |
> 1) imaginary |
| 25 |
> 2) currently impossible to support, because there are lots of |
| 26 |
> applications which either force gtk3 in the ebuild or have only gtk3 |
| 27 |
> supported upstream. It will be pretty much impossible to not have gtk3 |
| 28 |
> installed or loaded into RAM, unless you don't use a DE in the first |
| 29 |
> place and stick to terminals. |
| 30 |
> |
| 31 |
> > |
| 32 |
> >> |
| 33 |
> >> I think a lot of people just go wild when they see configure switches |
| 34 |
> >> and stuff everything into USE flags without really considering the |
| 35 |
> >> impact or the usefulness. |
| 36 |
> >> |
| 37 |
> >> It's not all about choice, it's also about sanity. |
| 38 |
> >> |
| 39 |
> > |
| 40 |
> > And again, I'm just saying to leave it up to the maintainer. |
| 41 |
> |
| 42 |
> If this affects tree consistency and usability, then it is not just up |
| 43 |
> to the maintainers. |
| 44 |
|
| 45 |
|
| 46 |
There are lots of topics where I concede that QA has a point and can |
| 47 |
utilize its influence; but 'consistency and usability' are not topics I |
| 48 |
would normally expect them to impose on developers. |
| 49 |
|
| 50 |
-A |
Archives