[X2Go-Dev] Bug#755: cannot upgrade x2goServer on fedora 20 using yum

[Mihai Moldovan]

On 18.03.2015 11:02 PM, Orion Poplawski wrote:
> On 03/18/2015 12:10 AM, Mihai Moldovan wrote:
>> On 25.01.2015 05:43 AM, Orion Poplawski wrote:
>>> [...]
>>>
>>> I could probably have the Fedora x2goserver package provide
>>> x2goserver-extensions to help with such situations.
>> Please do. For both Fedora and EPEL, if possible.
>>
>> I just had to work around this in
>> http://code.x2go.org/gitweb?p=x2gomatebindings.git;a=blobdiff;f=x2gomatebindings.spec;h=2e2485fe4e43d866ac09cd902fc45ce327ae8285;hp=49b80bed94a0e0455fe74ed824ce13e50695206a;hb=HEAD;hpb=df8c930d9294de22fa0aa14267ee4942f70b8939
>>
>> Thank you very much in advance.
>> [...]
> Sure, but why even have the x2goserver-extensions sub-package?  It requires
> x2goserver and x2goserver requires it, so you can't install one without the other.

To be *perfectly honest*? I don't know, ask Mike#1.

To my understanding, it helps keeping components separated, and if we
really must fix a specific component ONLY, we... could. Potentially. In
theory. If the current world was completely different. Not in reality
though, as we depend on x2goserver-version-release for each
sub-component. This is also true for the DPKG versions.

Anyway, even though the logic behind this may be flawed because the
packages really depend on each other in a circular fashion, it's
somewhat "natural" to have a specific component package for each component.

We might (really) want to consider merging the packages for the 4.1.0.0
release, unless I miss some important bit of information. I don't want
to do it for the old 4.0.1.x release line, unless we're going to have
another LTS release based on that, as suggested by Mike#1. (Avoid
flogging a dead horse and everything.)

Additionally, the same applies to x2goserver-xsession, which is
currently also a separate package in Fedora and EPEL, but is depending
on x2goserver and vice versa. *If* we do something like this, we do it
*consistently*.

Hence, for consistency's sake, I'd prefer upstream and downstream to
follow the same packaging layout.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20150322/befbe85c/attachment.pgp>