Comparing the Fedora and x2go versions of x2goserver.spec led me to these patches.
Most are pretty simple except perhaps the one renaming x2goserver-x2goagent to x2goagent - although I see now that I'm missing an:
Obsoletes: x2goserver-x2goagent < <some version>
I still really don't see the need for x2goagent-virtual.
Also, no active RedHat distro (RHEL5+) needs %defattr(-,root,root) anymore. I'm not sure about Suse, but I'd be very surprised.
-- 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
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.
Requires(post): Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=3d4179ccb387d65... for 4.0.1.x. Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=ac99220a697a51a... for 4.1.0.0.
I noticed that perl(DBD::SQLite) was only a post-scriptlet dependency, which should also have been a proper one. Added that to your patch.
While looking into that, I noticed we're using deprecated scriptlets and dependencies for update-mime-database and update-desktop-database. I have corrected that with https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=4c4731a43b8a723... for 4.0.1.x and https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=57da9b17713593e... for 4.1.0.0.
Also, I simplified systemd usage a bit and fixed the postun scriptlet to restart the service. We've missed that before. Commit for 4.0.1.x: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=08fa5002dba26ff... Commit for 4.1.0.0: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=463d650718bd995...
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?
Recommends: Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=844224248cd76f9... for 4.0.1.x. Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=b39fcf469e77e15... for 4.1.0.0.
I added guards for Fedora >= 21 and SUSE >= 11. More for documentation than real use, as we've dropped support for FC releases past 22 and OpenSUSE releases past 12. SLE 11 packages are still built, but we never supported SLE 10 to begin with.
While doing that, I have also downgraded this stuff to Suggests. Commit for 4.0.1.x: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=821022573beccad... Commit for 4.1.0.0: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=23ddee465c90dc5...
perl MODULE_COMPAT: Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=4cac807c4afa350... for 4.0.1.x. Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=72cda81fdcb906e... for 4.1.0.0.
Comments for 4.0.1.x: Well, strictly speaking, we *do* have perl modules within x2goserver, although these are installed to %{_libdir}/x2go. x2goserver-printing ships a perl script, but no modules, so I dropped it there. Also dropped for x2goserver-xsession (using perl internally in a bash script.) Note that your Fedora package seems to miss the dependency upon perl(Cwd), might be intentional, though.
Comments for 4.1.0.0: Applied as-is, for 4.1.0.0 your patch was appropriate.
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?
NXLIBDIR: NOT applied for 4.0.1.x (not using NXLIBDIR.) Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=ad4e21b5c0a00da... for 4.1.0.0.
.packlist: Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=1b7d84f53f26487... for 4.0.1.x. Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=3139846a227657b... for 4.1.0.0.
Sorting: Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=88358aba9f6c270... for 4.0.1.x. Applied as https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=20c61290e8ac4b3... for 4.1.0.0.
Also, no active RedHat distro (RHEL5+) needs %defattr(-,root,root) anymore. I'm not sure about Suse, but I'd be very surprised.
Sadly, SUSE still mandates and uses it everywhere. See https://en.opensuse.org/openSUSE:Specfile_guidelines#Permissions
I could guard everything off via %if 0%{?suse_version} ... %endif, but that probably doesn't make sense.
Mihai
... and of course two follow-up commits to fix syntax errors.
One for a not-removed %endif: In 4.0.1.x: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=1a5d3032f7a9a84... In 4.1.0.0: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=afceb74065816fa...
And another one for bad %{?fedora} macro usage: In 4.0.1.x: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=23b2080e1248f92... In 4.1.0.0: https://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=3a0d285b225207b...
All my bad, though.
Mihai
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
-
Mihai Moldovan -
Orion Poplawski