[Discuss] [Gt-eos] GSI-OpenSSH Packages for Ubuntu

[Frank Scheiner]

On 7/3/19 21:55, Mischa Salle wrote:
> On Wed, Jul 03, 2019 at 03:17:49PM +0200, Frank Scheiner wrote:
>> On 7/2/19 13:23, Mischa Salle wrote:
>> Would be nice to have, but I'm not sure about how much additional work that
>> is. Mattias would have to maintain an additional patch (set) for each
>> actively maintained Debian version (i.e. at least Sid, stable and
>> oldstable), as the patch (set) for Fedora is much smaller than the regular
>> one as they already integrate part of its functionality in their regular
>> OpenSSH - IIRC.
> 
> Not sure I fully understand. We have a set of patches and debian sources
> in the gct tree. Building those would use a specific version of openssh,
> not per se matching the OS native version, but that's not such a
> problem. Hence building it against different releases of Debian and
> Ubuntu shouldn't be that much problem or am I missing something?

Debian uses different versions of OpenSSH in different versions of Debian:


* Jessie (oldstable) - OpenSSH 6.7p1
* Stretch (stable) - OpenSSH 7.4p1
* Sid (unstable) - OpenSSH 7.9p1 => will also be in Buster (testing)

...taken from [1].

[1]: 
https://packages.debian.org/search?suite=all&searchon=names&keywords=openssh-server

I don't expect that our current patch set (for 7.5p1) applies to these 
OpenSSH versions without further modification - but I can be wrong.

UPDATE: Ok, I think I understand what you mean. Though I'm not sure if 
that's so easy:

Don't different Debian versions incl. Ubuntu versions link their OpenSSH 
to different versions of its dependencies? How do we know if our version 
will always work correctly with the respective dependency on a specific 
version of Debian or Ubuntu?

And what version of OpenSSH should we use, is the one in the GCT tree 
(7.5p1) still supported? I don't think so, so we would need to get or 
backport fixes from a 7.5p1 package that's still maintained somewhere.

But maybe I see problems where there are none.

>>> In any case the wording "pre-compiled packages" is probably a bit
>>> misleading.
>>
>> I always thought that this term would be common...
>>
>>> I'd probably just say "packages", since the src RPMs and
>>> debians are also available in those places.
>>
>> ...and also imply (or "include") source packages.
> Hmm, I don't think I'd call a source RPM a pre-compiled package, the
> compiler hasn't yet been called, nor is it actually a dependency for
> creating it.

Right, and there are also packages that don't contain compiled code at 
all. But I think at least in EPEL/Fedora/Debian/[...] you can't have 
packages w/o source packages, or is that possible?

>> Can we agree on "OS packages" to set them apart from the IMHO too generic
>> term "packages". I mean tarballs can also be considered packages in a way.
> Only if you're running Slackware (-;
> Both Debian and RedHat are talking about packages, package managers etc.
> I'm a bit reluctant calling them *OS* packages, since our packages
> aren't really part of the core OS

Ok, ok, then let's change that together because I already have a huge 
backlog. I'll take care of the GitHub releases page. Could you then 
create a PR for the gridcf.org website?

>, at least not for EPEL (which by the
> way isn't called EOSPEL). In any case this is probably nit-picking...

Cheers,
Frank

-- 
Frank Scheiner

High Performance Computing Center Stuttgart (HLRS)
Department Project User Management & Accounting

Email: scheiner at hlrs.de
Phone: +49 711 685 68039

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2293 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20190704/286b60a0/attachment-0001.p7s>