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 [email protected] Boulder, CO 80301 http://www.nwra.com _______________________________________________ x2go-dev mailing list [email protected] http://lists.x2go.org/listinfo/x2go-dev
