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@nwra.com Boulder, CO 80301 http://www.nwra.com