Re: Ogon packaging for Debian (was: Re: Bug#906072: Ogon packages available (Linux RDP Server))

[marcel@linux-ng.de]

June 2, 2020 9:43 AM, "Bernhard Miklautz" <bernhard.miklautz@shacknet.at> wrote:

> Hi,
> 
> On Tue, Jun 02, 2020 at 05:52:19AM +0000, Mike Gabriel wrote:
> 
>> On Mo 01 Jun 2020 18:04:15 CEST, marcel wrote:
>> On Mo 01 Jun 2020 10:41:45 CEST, Bernhard Miklautz wrote:
> However updating to the latest FreeRDP is on my map for a while. I'll
> try to move that up the list. Until then I'd cherry pick FreeRDP 2
> support. If I didn't miss anything the following commit should be
> sufficient:
> https://github.com/ogon-project/ogon/commit/47ac3c794ca9842261fc7008baffd5a3d7ff2ce7
> 
> So long,
> Bernhard

Hi Bernhard,

I just tried to build version 1.0.0 with the above patch (need additional modifications to apply) but build still fails on stable and unstable.

So just let me try to convince you, that creating a package based on the "stable"/"1.0.0" release is not the best way to go:

From what I know (and I may be wrong, so feel free to correct me):

a) The 1.0.0 release is 2 years old (and therefore based on a software stack at least that old)

b) There's never been a packaged ogon version (designed for end users)

c) There are quite some dependencies that duplicate system libraries/tools (x-backend, pulseaudio, xfont, ...) that (if I understood Mike correctly) will need a lot of cleanup work in order to make it into the debian repo at all

d) By packaging ogon it will be much easier for people to install and use it

e) The package will start somewhere in the "unstable"/"experimental" repo (I guess?)


So (based on c)+e) I expect it to be a long way to get a debian "stable" flag - enough time maybe to prepare/release an new "stable"/"1.1.0" release?


And we're trying to make ogon accessible to a new type of user:
Not some company that get's this software installed and maintained, but a "normal" User, that wants this stuff up an running my doing some "apt update && apt install" magic.


With the current "1.0.0" approach, I expect this things to happen:

To get things even running we will have to apply (significant) modifications to the 1.0.0 code base, even to get it compiling. We'll also get dependencies to new libraries/a new environment, that surely differs from the current 1.0.0 installations.

So there will be modifications (and maybe different behaviour != "stable") anyway.

In short:

I'd vote for a more progressive approach:

Maybe the current git state could be tagged as "1.0.1-dev" (or whatever you like) and we could start working with that (and later on switch to the new "stable"/"1.1.0" release).

I'd make things much easier, and instead of "wasting time" with backporting patches, this time could be spent on making this software usable for "everyone".

But that's just my point of view. I'd like to hear your opinion an that.

Bye,
  Marcel