Re: [gentoo-dev] non conflicting libressl?

[Patrick Steinhardt]

On Wed, Jan 29, 2020 at 10:27:04AM +0100, Jason A. Donenfeld wrote:
> For a long time now, OpenSMTPD stopped supporting OpenSSL, only
> supporting LibreSSL. For that reason Gentoo's opensmtpd ebuild is
> stuck on the 6.0 version. I'm not happy about this.

I've got OpenSMTPD v6.6.2-p1 running on Gentoo with OpenSSL 1.1
without any patches or problems whatsoever. So while upstream
encourages to use LibreSSL, OpenSSL is still supported by
OpenSMTPD. Quoting their CHANGES.md:

It's preferable to depend on LibreSSL as OpenSMTPD is written
and tested with that dependency. In addition, the features
parity is not respected, some features will not be available
with OpenSSL, like ECDSA server-side certificates support in
this release. OpenSSL library is considered as a best effort
target TLS library and provided as a commodity, LibreSSL has
become our target TLS library.

So as long as you don't require any features implemented with
libressl, only, you should be fine.

> It looks like other distros solve this by allowing libressl to install
> its libraries to /usr/lib/libressl or similar, so that they can
> coexist with openssl, allowing programs like OpenSMTPD.
> 
> Any libressl developers interested in this sort of thing?
> 
> Jason

Patrick


signature.asc
Description: PGP signature

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Patrick Steinhardt]

On Fri, Mar 23, 2018 at 03:25:12PM +0100, Arve Barsnes wrote:
> On 23 March 2018 at 14:27, Rich Freeman  wrote:
> > It sounds to me that one of the intended behaviors is to tell portage
> > that for a particular package we want to ignore a particular
> > repository entirely.  Suppose for example an overlay contains
> > misc/foo-3, and the main repo introduces misc/foo-4.  Perhaps we want
> > portage to stick with foo-3 from the overlay.  However, if the overlay
> > adds foo-4, or foo-4.1 we want this installed.  A version mask would
> > not really cover this use case.
> >
> > IMO this sounds like a useful feature.  Having it in profiles could
> > probably also be useful in some testing scenarios, such as when making
> > changes to a large number of packages that are already in the main
> > tree (think something analogous to a feature branch in git, where the
> > master branch continues to advance).
> 
> Unless I'm misunderstanding, this is possible already in package.mask?
> If the mask is not permanent (for testing, as you mention), would
> there be any benefit in having it in profile instead?
> 
> Putting misc/foo::gentoo in package.mask works fine either way.
> Probably  
> I use this for the opposite scenario, I have */*::overlay in
> package.mask, and unmask only a particular package in package.unmask,
> to avoid bringing in a lot of overlay packages without having a
> particular need.
> 
> Arve

This wouldn't help the maintainers of overlays, though, and puts
the burden on the user. One scenario where masks maintained in
overlays would be useful is the musl overlay, which carries
patches to various packages to have them compile with musl libc.
Obviously, I always want to use packages provided by the musl
overlay in case the same package from the Gentoo tree has build
failures. Even if the Gentoo-provided package gets updated, I'll
still want to use the older version from the musl tree, as the
build errors are likely to still exist.

If overlays were able to ignore packages from other repositories,
the musl overlay could simply mask out packages from the Gentoo
repository which are known to not compile on musl-based systems.
Like this, the user does not have to maintain these masks
manually, but they are already managed at a central place and
updated with the musl repository.

Patrick


signature.asc
Description: PGP signature