[Pkg-x2go-devel] Getting things started with x2goclient

[Reinhard Tartler]

[btw, no need to CC me, I do read the list after all]

On Tue, Feb 01, 2011 at 14:22:57 (CET), Mike Gabriel wrote:

> Hi Reinhart,
>
> On Di 01 Feb 2011 10:59:10 CET Reinhard Tartler wrote:
>
>> On Tue, Feb 01, 2011 at 10:38:06 (CET), Mike Gabriel wrote:
>>
>>> My basic idea would be to bundle source packages into one package if
>>> the versioning of the bundled packages will be the same.
>>>
>>> E.g.
>>>
>>>   nxcomp, nxcompext, nxcompshad -> nxlibs.git
>>
>> In general, it makes more sense to track upstream's structuring, and
>> AFAIUI (please correct me if I'm wrong), this is the structure is
>> provided from NoMachine. However, since 3.4 is reported to be the last
>> GPL'ed version of these libraries, from now on, the community needs to
>> do this upstream work independently from the actual upstream:
>>
>> http://www.nomachine.com/news-read.php?idnews=331
>>
>> So under this light, merging them all might make sense. Espc. the
>> nxproxy package is pretty silly.
>>
>> Still, I think this work should better be done upstream and not as part
>> of Debian Packaging, which AFAIUI is the purpose of pkg-x2go team.
>
> I know from Heinz that there is a thought that the X2go project  becomes
> the upstream location for these packages as NoMachine NX3 is  actually
> out of the NoMachine support...

Just as I expected.

> As code.x2go.git and the Uni-Erlangen git will be an X2go upstream
> location, we might choose to be free in the setup design.
>
> So the main question here is: is there an NX upstream that is still
> ,,alive''? If not, what steps are needed to transfer upstream to
> X2go-git.

Well, technically I'd say just create an nxlibs.git on code.x2go.org and
go ahead start merging the packages. This will however take some effort
to merge the Makefiles and buildsystem, can be pretty boring.

>>> Another example would be the thinclient environment...
>>> Yet another one the KDE admin tools: x2gouseradministration,
>>> x2gosystemadministration, etc.
>>>
>>> Currently, there is one .git folder for one binary package in Debian.
>>
>> False. Each of the library packages build a seperate lib* and *-dev
>> package.
>
> OK...
>
>>> I would rather like to see one .git folder per source package (in
>>> Debian or other distro).
>>
>> This is exactly what I'm proposing.
>
> So we should thing about a scheme that shows which binaries are
> included in which source package... I could do this some time next
> weekend. But if you have a proposal I am happy to comment on that.

Let's start with small steps and bottom up, and focus on the nxlibs
source package. That would then build the following binary packages:

libxcomp3
libxcomp-dev
libxcompext3
libxcompext-dev
libxcompshad3
libxcompshad-dev
nxproxy

Writing the packaging for that is little work for Jonas or me. But for
that we need a (upstream) source tree, from which the three libraries,
their headers and nxproxy are built.

Regarding nxagent: after having reviewed the source code, I think the
beast is more managable if it is keept seperate. The reason is that, as
indicated, it is an X11R6 fork with its buildsystem (imake), which is
really non-trivial to re-implement.  Having said this, I think *a lot*
of code can (and should!) be stripped out of the current nxagent source
tree!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4