On Mon, Nov 19, 2018 at 4:05 PM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

Control: close -1 Control: tags -1 not-a-bug

Hi Jens,

On Mo 19 Nov 2018 14:26:41 CET, Jens Reyer wrote:

...

$ cat /etc/apt/preferences.d/x2go-ppa Package: * Pin: release o=LP-PPA-x2go Pin-Priority: 1010

This is exactly the way to do it.

Closing this bug as a not-a-bug report.

I don't really get it. What is the sense in adding a ppa to your system when you need additional steps to get the packages from there!? This is counter-intuitive! If a user adds the ppa he/she/it states his/her/its will to use packages from there, so why ignoring that user wish?

Uli

Hi,

On Mo 19 Nov 2018 16:48:37 CET, Jens Reyer wrote:

Am Mo., 19. Nov. 2018 um 16:20 Uhr schrieb Ulrich Sibiller <ulrich.sibiller@gmail.com>:

...

On Mon, Nov 19, 2018 at 4:05 PM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

Control: close -1 Control: tags -1 not-a-bug

...

$ cat /etc/apt/preferences.d/x2go-ppa Package: * Pin: release o=LP-PPA-x2go Pin-Priority: 1010

This is exactly the way to do it.

Closing this bug as a not-a-bug report.

I don't really get it. What is the sense in adding a ppa to your system when you need additional steps to get the packages from there!? This is counter-intuitive! If a user adds the ppa he/she/it states his/her/its will to use packages from there, so why ignoring that user wish?

I basically agree with Uli, except that I'd only prefer newer versions from the PPA over those from the Ubuntu archive (which should be the case for nightly). Or with other words: I assume you update the upstream source in the orig.tar for the nightlies, then you should also change the upstream version.

The orig tarballs are indeed Git snapshots and the code base is newer
than the upstream release number given. In fact, the package version
contains the Git revision hash (shortened) and from that you can
derive what code is actually shipped in the package.

The overall idea is to have an easy upgrade path when you want to
return from nightly builds (test test test) back to a stable release
build.

Mike

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

Hi Mike,

Am Di., 20. Nov. 2018 um 10:07 Uhr schrieb Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:

Hi Uli,

On Mo 19 Nov 2018 16:19:47 CET, Ulrich Sibiller wrote:

...

On Mon, Nov 19, 2018 at 4:05 PM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

Control: close -1 Control: tags -1 not-a-bug

Hi Jens,

On Mo 19 Nov 2018 14:26:41 CET, Jens Reyer wrote:

...

$ cat /etc/apt/preferences.d/x2go-ppa Package: * Pin: release o=LP-PPA-x2go Pin-Priority: 1010

This is exactly the way to do it.

Closing this bug as a not-a-bug report.

I don't really get it. What is the sense in adding a ppa to your system when you need additional steps to get the packages from there!? This is counter-intuitive! If a user adds the ppa he/she/it states his/her/its will to use packages from there, so why ignoring that user wish?

Uli

It is a versioning topic. As long as we have not released a new upstream version, the nx-libs nightly packages we built for Arctica / X2Go are always strictly below the released package versions officially shipped in the distro.

So, you need to enforce that the nightly builds are preferred over the distro's nx-libs. This is wanted (by me).

And yes, it is counter intuitive for PPAs. This results from X2Go's nx-libs 3.6.x branch simply being synced over from Github.

Then maybe this can be documented on (at least) this page (including the apt preferences snippet): https://launchpad.net/~x2go/+archive/ubuntu/ppa

Greets and thanks again jre