[Pkg-nx-group] New darcs repository

[Per Olofsson]

Stefan Lippers-Hollmann:
> Like Roberto C. Sanchez and Alexander Wirt already mentioned, this is 
> probably a rather unfortunate VCS decision. I guess you weren't aware of
> 	svn://svn.debian.org/svn/pkg-nx/nxcomp/trunk/
> 	svn://svn.debian.org/svn/pkg-nx/nxcompext/trunk/
> 	svn://svn.debian.org/svn/pkg-nx/nxproxy/trunk/
> still in early work progress based on NX 1.4 for the reasons stated below, 
> but I'm actually more interested in your visions regarding NX packaging 
> for debian, than in re- using existing efforts.

I will move to SVN, nothing is set in stone.

> What are your plans regarding nx-X11/ nxagent, nxdesktop and nxviewer, 
> the potential "server" backend (FreeNX or 2X Software Ltd. nxserver?) and 
> a suitable client (if you plan to ship any client, nxssh and eventually 
> nxprint, nxspool and nxesd)? 

I plan to start with libXcomp and nxproxy. libXcomp is the base
component, and together with nxproxy and some script it's actually
usable.

> Are you aware that there currently is no dfsg free (non-ia32/ i386) 
> client for NX 2.0,

That depends on how you see it. Both nxcomp and nxproxy are DFSG free
TTBOMK, and they can be used as a client and server (albeit perhaps
not for connecting to the "official" server).

> while there are qtnx and 2X Software Ltd. nxclient 
> (both for about 3-4 weeks) so far depending on NX 1.5 and both licensed 
> under the GPL?

2.0 seems to be a better release. Won't the other clients eventually
move to NX 2.0 anyway?

> How do you plan to implement the file layout (FHS compliant or NoMachine 
> like)?

FHS. I'm not allowed (by policy) to use /usr/NX in Debian anyway.

> What is your proposed time frame for getting the source into a releasable 
> state, etch+1, etch+2? Especially considering that doing the necessary 
> code overhauls most likely aren't supported by NoMachine and would 
> effectively force you to become upstream yourself and fork the code 
> base - or have you already settled this question with upstream?

I don't have a timeframe, I'd just like to get the basic components at
least into Debian unstable. Whether they will be in etch or not
depends on how well they work. You need to start somewhere.

> How do you plan to counter the other issues I've enumerated [1]?

I'm sorry, I somehow missed that mail and I have no idea why. I
suppose the issues are bigger than I thought.

Still, the _basic_ components, nxcomp and nxproxy, from NX 2.0, seem
to work well and be fully DFSG-free. We can have them and NX 1.5 in
Debian at the same time. nxcomp has a different SONAME in 1.5 I
believe (libXcomp.so.1 vs libXcomp.so.2 in 2.0) so they can
coexist. And I can call the nxproxy package nxproxy2. So you can still
upload NX 1.5 from 2X Software if you wish.

> How do you plan to manage pristine upstream tarballs? You'll have to prune
> a significant amount of unused code and non dfsg free parts, besides that 
> NoMachine doesn't keep obsolete tarballs available for downloading.

We can always keep tarballs in Subversion or on the Alioth web space,
if needed. If there are non-dfsg free files, we can have a script in
debian/ for stripping them, to be run before uploading a new orig
tarball. Or we can have the upstream source in SVN. Doesn't matter
much to me.

> So far I've been working on getting 2X Software Ltd.'s code base for 
> NX 1.5 [2] into a buildable, but by far not suitable for debian, state - 
> very early work in progress is located at [3]. I tried to lay out a 
> foundation for a general overhaul of the code base in cooperation with 2X 
> Software Ltd., aiming for a long term solution for the questions mentioned 
> above.

Right, that sounds great, but a lot of work. As I said, the efforts
can continue in parallel. We'll just make sure we name our packages
different things so they won't collide.

-- 
Pelle