Re: [kde] setting an /opt precedent
>>"Jim" == Jim Gettys <email@example.com> writes:
Jim> The project has to be able to have more than one environment installed
Jim> simultaneously, both for development, and for users, *SINCE IT JUST ISN'T
Jim> POSSIBLE TO GET ALL APPLICATIONS MOVED SIMULTANEOUSLY*. The scale
Jim> of these projects is such there is no other way forward, but to enable
Jim> both versions to be used side by side, possibly simultaneously.
Why is this not an issue of backwards compatibility with their
installed based not a problem to ber solved by these projects? Why
isn't versioning of interfaces an integral part of their protocol?
This is a solved problem (DCE RPC solved it before Linux was born,
really, for one example). I see this as users having to work around
lack of design and due care for compatibility from the projects.
Jim> So somehow, some way, you need to be able to have more than one
Jim> version of the applications available so that users can choose
Jim> how much they are going to bleed (and similarly, libraries, header
Jim> files, etc).
Unless the projects can figure out compatibility issues, I
Jim> So, if you don't like /opt, then make a concrete suggestion to KDE
Jim> (and something similar may need to happen for Gnome) about where to
Jim> put things, rather than whining about FHS and the proper uses of /opt.
I see. Standards compliance is whining. Lets just up and throw
away policy while we are at it, and have everyone reinstall from
scratch like microsoft does.
Man invented language to satisfy his deep need to complain. Lily
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C