Re: VNC plans.
On Thu, Nov 21, 2002 at 02:21:18PM +, Andrew Suffield wrote: On Thu, Nov 21, 2002 at 01:49:33PM +0100, Ola Lundqvist wrote: 0) Start using alternatives for vnc. 0.1) Link svncviewer staically with libvncauth instead of dynamically. 1) Package tightvnc as: tightvncserver, provides vncserver tight[x?]vncclient, provides vncviewer tightvnc-doc The hard part is to test that they can coexist. Why do they need to coexist with the other implementation? They could simply conflict. Probably because I'm a person who wants to make everything good way. I will get bugs about why can they not coexist??! and to fix them I have to do this anyway, but in a easier way. :) 2) Change the vnc package to realvnc realvncserver, provides vncserver realvncviewer, provides vncviewer vnc-common (I have to check what's in there). These names suck. They imply that the other implementation is not real. Maybe something involving 'vanilla' would be better. Agreed! The problem is that (as people have told already) the new (the same crew as far as I know) upstream call themself realvnc... I think I stick to the upstream name. An other solution is to not change the name and make it provide rfbserver and rfbclient. Maybe that is not a bad solution after all. :) It makes it less hard for me ;) 3) Ask for the removal of the old vnc packages. For one release, make them metapackages that depend on the tightvnc packages - that way people who do nothing will continue to have the same packages that they always did (I presume that vnc* is tightvnc in woody). And with the new solution I do not have to make this step. 4) Change name of vnc-java to realvnc-java And not this either. 5) Package tightvnc-java. Same thing applies. 2) Do I have to ask for vncserver and vncviewer as they become virtual packages? Parse error. Policy requirement. Do I have to have this in official virtual package list (I maintain all the packages right now, including rfb if I want to)? Well I will probably ask for it anyway, but that is assuming that I get it to work at all. Regards, // Ola -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: VNC plans.
On Thu, Nov 21, 2002 at 06:04:15PM -0600, Oliver Xymoron wrote: 2) Change the vnc package to realvnc realvncserver, provides vncserver realvncviewer, provides vncviewer vnc-common (I have to check what's in there). Perhaps you should make the virtual package rfbserver and rfbviewer and ditch the 'real' bit. There's already an 'rfb' package in Debian that you should probably coordinate with. I'll do that. The rfb package already do that? Ohh I missed it. And I will coordinate with the rfb maintainer because I will take it over (already have an ok from the maintainer). Regards, // Ola -- Love the dolphins, she advised him. Write by W.A.S.T.E.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: VNC plans.
On Fri, Nov 22, 2002 at 07:11:47AM +0100, Ola Lundqvist wrote: Agreed! The problem is that (as people have told already) the new (the same crew as far as I know) upstream call themself realvnc... I think I stick to the upstream name. An other solution is to not change the name and make it provide rfbserver and rfbclient. Maybe that is not a bad solution after all. :) It makes it less hard for me ;) Sounds like a plan. Technical reasons are always better than aesthetic ones. 2) Do I have to ask for vncserver and vncviewer as they become virtual packages? Parse error. Policy requirement. Do I have to have this in official virtual package list (I maintain all the packages right now, including rfb if I want to)? Well I will probably ask for it anyway, but that is assuming that I get it to work at all. Then no, you don't. It was probably a mistake to ever attempt to codify the list of virtual packages in policy. Agreement amoung the people involved is sufficient. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK
Re: VNC plans.
On Fri, Nov 22, 2002 at 09:56:52AM +, Andrew Suffield wrote: Then no, you don't. It was probably a mistake to ever attempt to codify the list of virtual packages in policy. Agreement amoung the people involved is sufficient. I disagree. The nature of the agreement needs to be documented somewhere, so that when a new maintainer joins and packages something that might qualify to use the virtual package, he: * knows there is such a thing * can determine from the definition of the virtual package whether or not his package actually qualifies For instance, someone packaging yet another terminal emulator or window manager for X should not completely ignore the virtual packages for these things, which is more likely if you have to know the right people, instead of having an FM to R. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn pgp85yFtitxYy.pgp Description: PGP signature
Re: VNC plans.
Why do they need to coexist with the other implementation? They could simply conflict. They shouldn't.
Re: VNC plans.
On Thu, Nov 21, 2002 at 01:49:33PM +0100, Ola Lundqvist wrote: Hello Some people might have notived that I have made some (dramatic?) changes to the vnc packages. The reason is that the upstream development have started again. :) The problem is that I used to have the tightvnc patches applied but due to the upstreams is so different, that is not possible anymore. The new upstream has nice new features and tightvnc has other nice features. They may coexist in the future but that is far away. So this is what I intend to do to solve these issues: 0) Start using alternatives for vnc. 0.1) Link svncviewer staically with libvncauth instead of dynamically. 1) Package tightvnc as: tightvncserver, provides vncserver tight[x?]vncclient, provides vncviewer tightvnc-doc The hard part is to test that they can coexist. 2) Change the vnc package to realvnc realvncserver, provides vncserver realvncviewer, provides vncviewer vnc-common (I have to check what's in there). Perhaps you should make the virtual package rfbserver and rfbviewer and ditch the 'real' bit. There's already an 'rfb' package in Debian that you should probably coordinate with. -- Love the dolphins, she advised him. Write by W.A.S.T.E..