[X2Go-Dev] Various x2goserver patches

Orion Poplawski orion at cora.nwra.com
Mon Mar 6 18:08:05 CET 2017


On 03/06/2017 01:52 AM, Mihai Moldovan wrote:
> On 06.01.2017 05:19 PM, Orion Poplawski wrote:
>> Comparing the Fedora and x2go versions of x2goserver.spec led me to these patches.
> 
> I finally found some time to go through your patches and apply (most of) them.
> Sorry it took me so long.

No worries, and thanks.

>   This said, we have a problem that I haven't noticed before. You install
> x2gocleansessions.service - we install x2goserver.service. Only
> x2gocleansessions.service is enabled in Fedora's default preset file. I agree
> that x2gocleansessions.service is probably better at describing what it does -
> but we have historically used x2goserver.service (also for the init script.)
>   Even worse, we can only activate the service by default on Fedora (if it's
> appropriately named), but not on RHEL, CentOS or *SUSE. Do you think it might be
> better to place systemctl enable/disable commands somewhere for our upstream and
> your EPEL packages? If yes, what is the canonical way to do so?

x2gocleansessions.service is enabled by default in EPEL via the preset file in
epel-release.

For your packages I think you need to add "systemctl enable x2goserver.service"

> Note that your Fedora package seems to miss the dependency upon perl(Cwd), might
> be intentional, though.

No, I was depending on the automatic dep generator, but it doesn't catch that
usage.  Thanks.

> x2goagent:
>   NOT applied.
> 
>   The situation with x2goagent is complicated and I'd really appreciate your
> help on that. x2goserver 4.0.1.x only supports the x2goagent that is shipped by
> nx-libs and only nx-libs as distributed by X2Go. x2goserver 4.1.0.0, however,
> supports nx-libs provided by X2Go and Arctica. Arctica has removed the x2goagent
> package, this is why we need x2goserver-x2goagent. Our nx-libs package doesn't
> drop x2goagent. I cannot just rename x2goserver-x2goagent to nxagent, because
> X2Go's nx-libs also have a package called x2goagent. I could do a package move
> from nx-libs to x2goserver, but that would require a lockstep release of both
> nx-libs and x2goserver and proper dependencies, so that the package is
> transferred transparently without users running into problems when upgrading. My
> current solution is to make nx-libs' x2goagent package provide a virtual
> x2goagent-virtual package and x2goserver-x2goagent also provide
> x2goagent-virtual AND depend upon nxagent from Arctica's nx-libs. I notice that
> I should probably add a Conflicts: nxagent >= 3.5.99 clause to our nx-libs'
> x2goagent subpackage.
>   What I probably really want is a proper package move from nx-libs to
> x2goserver. It's tricky, though, because x2goserver depends upon x2goagent - and
> the newer x2goagent version will install files that were previously installed by
> x2goserver, so x2goagent needs to be upgraded only AFTER x2goserver has been
> upgraded, while for general usage x2goserver needs the new x2goagent version at
> run time to function properly.
>   Looks like I cannot avoid a lockstep release of both components and the
> package move from nx-libs to x2goagent even for x2goserver 4.0.1.x?

I *think* you're making this much more complicated than it really is, unless I
keep missing something.  In a X2Go only repo, if you ship "x2goagent" in an
updated x2goserver package, the x2goagent package will simply be updated from
say 3.5.0.32-3 to 4.1.0.0-1.  These packages contain the same files, so no
problem.  There is no need for the old nx-libs package to drop x2goagent.


Some other differences I note:

- logcheck - We don't require it, and there is no need for a BuildRequires on
it either.

- No need to BR sudo.

- Does -common really require perl?

- I have common, xsession, perl-X2Go-Server, and perl-X2Go-Log as noarch
sub-packages.  This requires EL6+, not sure about SUSE.

- Database requires.  You have:

Requires(post): perl(DBD::SQLite)
Requires:       perl(DBD::SQLite)
Requires:       perl(DBD::Pg)

I've debated about what is appropriate here, since you can use either sqlite
or postgress.  I have just the post requires as that is needed for the stock
install, but afterwards one should be able to install or remove either I would
think.



-- 
Orion Poplawski
Technical Manager                          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                   http://www.nwra.com


More information about the x2go-dev mailing list