Re: [kde] setting an /opt precedent
>>"Jim" == Jim Gettys <jg@pa.dec.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
guess so.
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.
manoj
annoyed
--
Man invented language to satisfy his deep need to complain. Lily
Tomlin
Manoj Srivastava <srivasta@debian.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
Reply to: