[gentoo-dev] libpcre.so.3 - Compatibility with Debian

[gentoo-dev] libpcre.so.3 - Compatibility with Debian

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hello all,

We, like almost everyone else and presumably upstream, install PCRE 8
as libpcre.so.1. Debian, for reasons best known to themselves, install
it as libpcre.so.3. With Ubuntu still being the most widely accepted
"standard" Linux desktop, this presents a problem when dealing with
pre-compiled binaries.

I have been working on a script to replace the rather lacking
steam-games-meta ebuild (see steam-overlay). I'm very excited about
releasing it soon as I think it is a major step forwards in our ability
to easily run Steam without the official Ubuntu-based runtime.

Before I put it out there, I'd like to get Alien Isolation working
properly. It links to libpcre.so.3. Hacking the binary might work but
this isn't ideal and not always an option as some games use Valve's
anti-cheat system, which is ruthless.

I have found that creating a symlink in /usr/lib that points
to /lib/libpcre.so.1 works, except that when you run ldconfig, it
automatically creates another symlink from /usr/lib/libpcre.so.1 to
libpcre.so.3. If you create the first symlink in /lib instead then the
existing /lib/libpcre.so.1 holds after running ldconfig. The latter
location is therefore probably preferable.

Would anyone have any issue with adding this to our libpcre package? I
don't foresee any problems. libpcre.so would obviously still point to
libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
as upstream have released PCRE2 as libpcre2, effectively an entirely
separate library.

I could create a Steam-specific package for this but that would mean
adding some additional Steam-specific location to ld.so.conf, which I'm
trying to avoid. It would be nice to solve this generally anyway.

Thoughts?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

On Thu, 11 Aug 2016 00:10:53 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> Hello all,
> 
> We, like almost everyone else and presumably upstream, install PCRE 8
> as libpcre.so.1. Debian, for reasons best known to themselves, install
> it as libpcre.so.3. With Ubuntu still being the most widely accepted
> "standard" Linux desktop, this presents a problem when dealing with
> pre-compiled binaries.
> 
> I have been working on a script to replace the rather lacking
> steam-games-meta ebuild (see steam-overlay). I'm very excited about
> releasing it soon as I think it is a major step forwards in our
> ability to easily run Steam without the official Ubuntu-based runtime.
> 
> Before I put it out there, I'd like to get Alien Isolation working
> properly. It links to libpcre.so.3. Hacking the binary might work but
> this isn't ideal and not always an option as some games use Valve's
> anti-cheat system, which is ruthless.
> 
> I have found that creating a symlink in /usr/lib that points
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> automatically creates another symlink from /usr/lib/libpcre.so.1 to
> libpcre.so.3. If you create the first symlink in /lib instead then the
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
> location is therefore probably preferable.
> 
> Would anyone have any issue with adding this to our libpcre package? I
> don't foresee any problems. libpcre.so would obviously still point to
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
> as upstream have released PCRE2 as libpcre2, effectively an entirely
> separate library.
> 
> I could create a Steam-specific package for this but that would mean
> adding some additional Steam-specific location to ld.so.conf, which
> I'm trying to avoid. It would be nice to solve this generally anyway.
> 
> Thoughts?
> 

I'd say this is the sort of thing that has more application than just
steam.

I'd just suggest a libpcre-debian package, which provides the .so via
symlink and dependency mechanisms.

That way *if* anything happens in the future, we can just introduce
blockers in the right place.

Then the applicable stuff depends on libpcre-debian for the forseeable
future.

And this way, if debian do anything else magical, we can probably copy
them and build a libpcre like they do for interop.

Essentially, the point here is to see debians libpcre is a competing
implementation, even though we can locally pretend they're not at the
technical level, it works as " conceptual model " for the problem we
have.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:

> We, like almost everyone else and presumably upstream, install PCRE 8
> as libpcre.so.1. Debian, for reasons best known to themselves, install
> it as libpcre.so.3. With Ubuntu still being the most widely accepted
> "standard" Linux desktop, this presents a problem when dealing with
> pre-compiled binaries.

Have you asked Debian why they are doing that?

> [...]

> I have found that creating a symlink in /usr/lib that points
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> automatically creates another symlink from /usr/lib/libpcre.so.1 to
> libpcre.so.3. If you create the first symlink in /lib instead then the
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
> location is therefore probably preferable.

> Would anyone have any issue with adding this to our libpcre package? I
> don't foresee any problems. libpcre.so would obviously still point to
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
> as upstream have released PCRE2 as libpcre2, effectively an entirely
> separate library.

This looks like a bad hack. As you said above, it will confuse
ldconfig, unless some trickery with /lib vs /usr/lib is used.

IMHO providing compatibility symlinks for proprietary binary-only
programs isn't the task of the libpcre package. Patch the binary, or
have the depending package create the libpcre.so.3 symlink, but not in
/usr/lib or /lib, but in a location specific to that package.

I remember that long time ago we had a similar issue with motif and
icaclient (motif installing .so.4 but icaclient linking to .so.3).
See: https://bugs.gentoo.org/show_bug.cgi?id=204264#c4

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[James Le Cuirot]

On Thu, 11 Aug 2016 11:43:41 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:  
> 
> > We, like almost everyone else and presumably upstream, install PCRE
> > 8 as libpcre.so.1. Debian, for reasons best known to themselves,
> > install it as libpcre.so.3. With Ubuntu still being the most widely
> > accepted "standard" Linux desktop, this presents a problem when
> > dealing with pre-compiled binaries.  
> 
> Have you asked Debian why they are doing that?

I did find out but had since forgotten. Here it is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10

On that basis, this is a safe thing to do. They are indeed the same
version and there is no incompatibility.

> > [...]  
> 
> > I have found that creating a symlink in /usr/lib that points
> > to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> > automatically creates another symlink from /usr/lib/libpcre.so.1 to
> > libpcre.so.3. If you create the first symlink in /lib instead then
> > the existing /lib/libpcre.so.1 holds after running ldconfig. The
> > latter location is therefore probably preferable.  
> 
> > Would anyone have any issue with adding this to our libpcre
> > package? I don't foresee any problems. libpcre.so would obviously
> > still point to libpcre.so.1. I'm pretty sure there will never be
> > another libpcre.so.3 as upstream have released PCRE2 as libpcre2,
> > effectively an entirely separate library.  
> 
> This looks like a bad hack. As you said above, it will confuse
> ldconfig, unless some trickery with /lib vs /usr/lib is used.

I wouldn't call it trickery. Here's what happens when you put it
in /lib. I can't see anything wrong here?

# cd /lib
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
# ln -s libpcre.so.1 libpcre.so.3
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1
# ldconfig
# ls -l libpcre.*
lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
-rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1

> IMHO providing compatibility symlinks for proprietary binary-only
> programs isn't the task of the libpcre package.

I'm fine with putting it in libpcre-debian package as kentnl suggested.

> I remember that long time ago we had a similar issue with motif and
> icaclient (motif installing .so.4 but icaclient linking to .so.3).
> See: https://bugs.gentoo.org/show_bug.cgi?id=204264#c4

I've read through that and but I don't believe this is falling foul in
the same way. The icaclient package should not have installed a
potentially conflicting libXm symlink; libpcre-debian would be an
appropriate package. It also pointed libXm.so.3 to a different
underlying version, which may have caused breakage in other situations;
the libpcre symlink would point to the same version.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:

>> Have you asked Debian why they are doing that?

> I did find out but had since forgotten. Here it is:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10

So they are aware of the issue since 10 years, but chose not to fix
it? Seriously, there's no good reason to dance to their tune then.

>> This looks like a bad hack. As you said above, it will confuse
>> ldconfig, unless some trickery with /lib vs /usr/lib is used.

> I wouldn't call it trickery. Here's what happens when you put it
> in /lib. I can't see anything wrong here?

> # cd /lib
> # ls -l libpcre.*
> lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
> -rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
> # ln -s libpcre.so.1 libpcre.so.3
> # ls -l libpcre.*
> lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
> -rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
> lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1
> # ldconfig
> # ls -l libpcre.*
> lrwxrwxrwx 1 root root     16 Jul 12 23:29 libpcre.so.1 -> libpcre.so.1.2.7
> -rwxr-xr-x 1 root root 464960 Jul 12 23:29 libpcre.so.1.2.7
> lrwxrwxrwx 1 root root     12 Aug 11 11:01 libpcre.so.3 -> libpcre.so.1

>> IMHO providing compatibility symlinks for proprietary binary-only
>> programs isn't the task of the libpcre package.

> I'm fine with putting it in libpcre-debian package as kentnl
> suggested.

I still think that the libpcre.so.3 compatibility link shouldn't be
installed in a generally visible location. Install it in a specific
directory instead, and start your binary with a wrapper which will
add that directory to LD_LIBRARY_PATH.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[James Le Cuirot]

On Thu, 11 Aug 2016 12:56:02 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >> IMHO providing compatibility symlinks for proprietary binary-only
> >> programs isn't the task of the libpcre package.  
> 
> > I'm fine with putting it in libpcre-debian package as kentnl
> > suggested.  
> 
> I still think that the libpcre.so.3 compatibility link shouldn't be
> installed in a generally visible location. Install it in a specific
> directory instead, and start your binary with a wrapper which will
> add that directory to LD_LIBRARY_PATH.

That makes it slightly more awkward for binaries you may have installed
manually. Can we agree to disagree on this one? It won't affect those
who don't need it. Obviously if anything blows up, I'll take full
responsibility.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1124 bytes --]

On 08/11/2016 01:20 PM, James Le Cuirot wrote:
> On Thu, 11 Aug 2016 12:56:02 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
>>>> IMHO providing compatibility symlinks for proprietary binary-only
>>>> programs isn't the task of the libpcre package.  
>>
>>> I'm fine with putting it in libpcre-debian package as kentnl
>>> suggested.  
>>
>> I still think that the libpcre.so.3 compatibility link shouldn't be
>> installed in a generally visible location. Install it in a specific
>> directory instead, and start your binary with a wrapper which will
>> add that directory to LD_LIBRARY_PATH.
> 
> That makes it slightly more awkward for binaries you may have installed
> manually. Can we agree to disagree on this one? It won't affect those
> who don't need it. Obviously if anything blows up, I'll take full
> responsibility.
> 

I agree with Ulm on this one, having a separate dir and LD_LIBRARY_PATH
seems like the cleanest solution for this.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:

> That makes it slightly more awkward for binaries you may have
> installed manually.

It is impossible to support all third-party binaries, especially if
they link against non-standard libraries because they aim for bug
compatibility with another distro.

Users manually installing such things can easily create any needed
compatibility symlinks in their /usr/local/lib*.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Rich Freeman]

On Thu, Aug 11, 2016 at 8:04 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:
>
>> That makes it slightly more awkward for binaries you may have
>> installed manually.
>
> It is impossible to support all third-party binaries, especially if
> they link against non-standard libraries because they aim for bug
> compatibility with another distro.
>
> Users manually installing such things can easily create any needed
> compatibility symlinks in their /usr/local/lib*.
>

It doesn't hurt for people to try to provide compatibility when the
changes are minor though.

It is nice to have the steam overlay around.  Though, if things got
bad enough I imagine I'd take the time to figure out how to just get
Ubuntu+Steam working in a container.  For binary packages sometimes it
is easier to just go the path of least resistance.  Though, when X11
is involved containers aren't always painless.

-- 
Rich

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller:
> > > > > > On Thu, 11 Aug 2016, James Le Cuirot wrote:
> 
> > > Have you asked Debian why they are doing that?
> 
> > I did find out but had since forgotten. Here it is:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10
> 
> So they are aware of the issue since 10 years, but chose not to fix
> it? Seriously, there's no good reason to dance to their tune then.

It's not to dance to Debians tune, it's to dance to Valve tunes, which
happens to create its runtimes from Ubuntu packages.
I strongly believe that it's important to have such a use case as Steam
work problem-free in Gentoo. It's currently too messy, with and without
using steam runtime.
In the former case (using steam runtime), there are incompatibilities
between libraries found in the steam runtime, and those that it doesn't
include and assumes the system provides (primarily mesa and deps); each
steam runtime version you get to hack around things by removing a small
selection of libraries from the steam runtime dir to get stuff working;
a 1-2 month old upgrade I haven't even managed to get to work yet on a
more up to date machine.
In the latter case (forcing to not use steam runtime), it's near
impossible right now to get a set of 32bit binaries to satisfy even
steam client itself without lots of trial and error, let alone some
32bit game.

> > I'm fine with putting it in libpcre-debian package as kentnl
> > suggested.
> 
> I still think that the libpcre.so.3 compatibility link shouldn't be
> installed in a generally visible location. Install it in a specific
> directory instead, and start your binary with a wrapper which will
> add that directory to LD_LIBRARY_PATH.

Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
toolchain.eclass function does, except for pointing libpcre.so.3 to
libpcre.so.1 (so can't use that eclass function, but could just pre-
create one to $FILESDIR if it works)?
The important points should be:
1) No compilation/linking done on Gentoo should possibly end up with
putting libpcre.so.3 in its DT_NEEDED
2) libpcre.so should link to libpcre.so.1

If we can satisfy these, I don't see a reason to mess around with some
extra package.
Debian reasoning of having stuck with libpcre.so.3 historically is
sound as well, especially if upstream will never use that, given
libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and
given debians todays situation with this, I would also technically
choose not to change this, as things should migrate over to PCRE2.


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ciaran McCreesh]

On Thu, 11 Aug 2016 17:57:59 +0300
Mart Raudsepp <leio@gentoo.org> wrote:
> I strongly believe that it's important to have such a use case as
> Steam work problem-free in Gentoo.

Steam isn't a use case, it's a program.

-- 
Ciaran McCreesh

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 3203 bytes --]

On 11/08/16 10:57 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller:
>>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:
>>
>>>> Have you asked Debian why they are doing that?
>>
>>> I did find out but had since forgotten. Here it is:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10
>>
>> So they are aware of the issue since 10 years, but chose not to fix
>> it? Seriously, there's no good reason to dance to their tune then.
> 
> It's not to dance to Debians tune, it's to dance to Valve tunes, which
> happens to create its runtimes from Ubuntu packages.
> I strongly believe that it's important to have such a use case as Steam
> work problem-free in Gentoo. It's currently too messy, with and without
> using steam runtime.
> In the former case (using steam runtime), there are incompatibilities
> between libraries found in the steam runtime, and those that it doesn't
> include and assumes the system provides (primarily mesa and deps); each
> steam runtime version you get to hack around things by removing a small
> selection of libraries from the steam runtime dir to get stuff working;
> a 1-2 month old upgrade I haven't even managed to get to work yet on a
> more up to date machine.
> In the latter case (forcing to not use steam runtime), it's near
> impossible right now to get a set of 32bit binaries to satisfy even
> steam client itself without lots of trial and error, let alone some
> 32bit game.
> 
>>> I'm fine with putting it in libpcre-debian package as kentnl
>>> suggested.
>>
>> I still think that the libpcre.so.3 compatibility link shouldn't be
>> installed in a generally visible location. Install it in a specific
>> directory instead, and start your binary with a wrapper which will
>> add that directory to LD_LIBRARY_PATH.
> 
> Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> toolchain.eclass function does, except for pointing libpcre.so.3 to
> libpcre.so.1 (so can't use that eclass function, but could just pre-
> create one to $FILESDIR if it works)?
> The important points should be:
> 1) No compilation/linking done on Gentoo should possibly end up with
> putting libpcre.so.3 in its DT_NEEDED
> 2) libpcre.so should link to libpcre.so.1
> 
> If we can satisfy these, I don't see a reason to mess around with some
> extra package.
> Debian reasoning of having stuck with libpcre.so.3 historically is
> sound as well, especially if upstream will never use that, given
> libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and
> given debians todays situation with this, I would also technically
> choose not to change this, as things should migrate over to PCRE2.
> 
> 
> Mart
> 


Wouldn't the most simple solution here would be to make a symlink for
libpcre.so.3 within the local bindir for each Valve or whatever
package that needs it?  This is a binary-package-supporting hack,
might as well do it in the binary packages that need it.  You might
still need to wrap the binary to set some environment stuff, not sure;
either way it doesn't seem to make sense to make this a system-wide thing.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 11:05, kirjutas Ian Stakenvicius:
> Wouldn't the most simple solution here would be to make a symlink for
> libpcre.so.3 within the local bindir for each Valve or whatever
> package that needs it?  This is a binary-package-supporting hack,
> might as well do it in the binary packages that need it.  You might
> still need to wrap the binary to set some environment stuff, not
> sure;
> either way it doesn't seem to make sense to make this a system-wide
> thing.
> 

It makes sense, IF it doesn't hurt absolutely anything as a by-product.
Also open source stuff should be gradually moving over to pcre2,
eventually ending up with libpcre.so being for binary packages
exclusively in due time anyways.


Ühel kenal päeval, N, 11.08.2016 kell 16:03, kirjutas Ciaran McCreesh:
> On Thu, 11 Aug 2016 17:57:59 +0300
> Steam isn't a use case, it's a program.

Use case is proprietary gaming and software, if that makes you happier
and avoids further useless e-mails due to feeling like nitpicking on a
perhaps very slightly wrong terminology.
Having specifically Steam hassle-free is also important on the desktop,
unless your only goal is to be a FSF endorsed distribution. But it
covers all proprietary software that targets and tests stuff working on
Debian/Ubuntu (which is the majority of cases, sadly).


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mike Gilbert]

On Thu, Aug 11, 2016 at 1:53 AM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 11 Aug 2016 00:10:53 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
>
>> Hello all,
>>
>> We, like almost everyone else and presumably upstream, install PCRE 8
>> as libpcre.so.1. Debian, for reasons best known to themselves, install
>> it as libpcre.so.3. With Ubuntu still being the most widely accepted
>> "standard" Linux desktop, this presents a problem when dealing with
>> pre-compiled binaries.
>>
>> I have been working on a script to replace the rather lacking
>> steam-games-meta ebuild (see steam-overlay). I'm very excited about
>> releasing it soon as I think it is a major step forwards in our
>> ability to easily run Steam without the official Ubuntu-based runtime.
>>
>> Before I put it out there, I'd like to get Alien Isolation working
>> properly. It links to libpcre.so.3. Hacking the binary might work but
>> this isn't ideal and not always an option as some games use Valve's
>> anti-cheat system, which is ruthless.
>>
>> I have found that creating a symlink in /usr/lib that points
>> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
>> automatically creates another symlink from /usr/lib/libpcre.so.1 to
>> libpcre.so.3. If you create the first symlink in /lib instead then the
>> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
>> location is therefore probably preferable.
>>
>> Would anyone have any issue with adding this to our libpcre package? I
>> don't foresee any problems. libpcre.so would obviously still point to
>> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
>> as upstream have released PCRE2 as libpcre2, effectively an entirely
>> separate library.
>>
>> I could create a Steam-specific package for this but that would mean
>> adding some additional Steam-specific location to ld.so.conf, which
>> I'm trying to avoid. It would be nice to solve this generally anyway.
>>
>> Thoughts?
>>
>
> I'd say this is the sort of thing that has more application than just
> steam.
>
> I'd just suggest a libpcre-debian package, which provides the .so via
> symlink and dependency mechanisms.
>
> That way *if* anything happens in the future, we can just introduce
> blockers in the right place.
>
> Then the applicable stuff depends on libpcre-debian for the forseeable
> future.
>
> And this way, if debian do anything else magical, we can probably copy
> them and build a libpcre like they do for interop.
>
> Essentially, the point here is to see debians libpcre is a competing
> implementation, even though we can locally pretend they're not at the
> technical level, it works as " conceptual model " for the problem we
> have.
>

Just here to add a +1 to this idea.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/10/2016 06:10 PM, James Le Cuirot wrote:
> Hello all,
>
> We, like almost everyone else and presumably upstream, install PCRE 8
> as libpcre.so.1. Debian, for reasons best known to themselves, install
> it as libpcre.so.3. With Ubuntu still being the most widely accepted
> "standard" Linux desktop, this presents a problem when dealing with
> pre-compiled binaries.
>
> I have been working on a script to replace the rather lacking
> steam-games-meta ebuild (see steam-overlay). I'm very excited about
> releasing it soon as I think it is a major step forwards in our ability
> to easily run Steam without the official Ubuntu-based runtime.
>
> Before I put it out there, I'd like to get Alien Isolation working
> properly. It links to libpcre.so.3. Hacking the binary might work but
> this isn't ideal and not always an option as some games use Valve's
> anti-cheat system, which is ruthless.
>
> I have found that creating a symlink in /usr/lib that points
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> automatically creates another symlink from /usr/lib/libpcre.so.1 to
> libpcre.so.3. If you create the first symlink in /lib instead then the
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
> location is therefore probably preferable.
>
> Would anyone have any issue with adding this to our libpcre package? I
> don't foresee any problems. libpcre.so would obviously still point to
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
> as upstream have released PCRE2 as libpcre2, effectively an entirely
> separate library.
>
> I could create a Steam-specific package for this but that would mean
> adding some additional Steam-specific location to ld.so.conf, which I'm
> trying to avoid. It would be nice to solve this generally anyway.
>
> Thoughts?


Whilst devs are discussing the future of Valve's offerings on gentoo, 
it'd be wise to consider the effects of "Vulcan" as it is FOSS where all 
video card vendors can inter-operate with multiple game vendors. Vulcan 
will impact  those gaming codes, as Vulcan seems to be the clear pathway 
forward for Valve related to Open Source communities [1 3].


[1] 
http://www.kitguru.net/components/graphic-cards/anton-shilov/valve-directx-12-does-not-make-a-lot-of-sense-vulkan-does/

[2] 
http://www.pcgamesn.com/khronos-and-valve-reveal-details-of-vulkan-api-show-dota-2-running-in-source-2-on-intel-integrated-graphics

[3] 
https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api


hth,
James

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 11:23, kirjutas james:
> Whilst devs are discussing the future of Valve's offerings on
> gentoo, 
> it'd be wise to consider the effects of "Vulcan" as it is FOSS where
> all 
> video card vendors can inter-operate with multiple game vendors.
> Vulcan 
> will impact  those gaming codes, as Vulcan seems to be the clear
> pathway 
> forward for Valve related to Open Source communities [1 3].

I have no idea what Vulcan is, besides the race in Star Trek or Roman
god, but Vulkan is tracked in https://bugs.gentoo.org/574886 and Intel
support in https://bugs.gentoo.org/580148

I was going to look into it as well on basis of Intel Vulkan with
dota2, but on that machine Steam doesn't even work anymore due to
https://github.com/ValveSoftware/steam-for-linux/issues/4537
so got rather demotivated. Basically a case where having a fully
working setup without steam runtime should also fix it. Current main
machine has Radeon Evergreen and so no current Vulkan implementation to
play with.


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Matt Turner]

On Thu, Aug 13, 2026 at 11:27 AM, james <garftd@verizon.net> wrote:
> be able to offer guidance, hence, I have filed no bugs on Vulcan. I'm not

The API is Vulkan with a k. Vulcan is where Spock is from.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Deven Lahoti]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

On Aug 11, 2016 1:03 PM, "Matt Turner" <mattst88@gentoo.org> wrote:
> The API is Vulkan with a k. Vulcan is where Spock is from.

Thanks for contributing to the discussion.

[-- Attachment #2: Type: text/html, Size: 276 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Patrick McLean]

On Thu, 11 Aug 2016 17:53:31 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> On Thu, 11 Aug 2016 00:10:53 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
> > Hello all,
> > 
> > We, like almost everyone else and presumably upstream, install PCRE
> > 8 as libpcre.so.1. Debian, for reasons best known to themselves,
> > install it as libpcre.so.3. With Ubuntu still being the most widely
> > accepted "standard" Linux desktop, this presents a problem when
> > dealing with pre-compiled binaries.
> > 
> > I have been working on a script to replace the rather lacking
> > steam-games-meta ebuild (see steam-overlay). I'm very excited about
> > releasing it soon as I think it is a major step forwards in our
> > ability to easily run Steam without the official Ubuntu-based
> > runtime.
> > 
> > Before I put it out there, I'd like to get Alien Isolation working
> > properly. It links to libpcre.so.3. Hacking the binary might work
> > but this isn't ideal and not always an option as some games use
> > Valve's anti-cheat system, which is ruthless.
> > 
> > I have found that creating a symlink in /usr/lib that points
> > to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> > automatically creates another symlink from /usr/lib/libpcre.so.1 to
> > libpcre.so.3. If you create the first symlink in /lib instead then
> > the existing /lib/libpcre.so.1 holds after running ldconfig. The
> > latter location is therefore probably preferable.
> > 
> > Would anyone have any issue with adding this to our libpcre
> > package? I don't foresee any problems. libpcre.so would obviously
> > still point to libpcre.so.1. I'm pretty sure there will never be
> > another libpcre.so.3 as upstream have released PCRE2 as libpcre2,
> > effectively an entirely separate library.
> > 
> > I could create a Steam-specific package for this but that would mean
> > adding some additional Steam-specific location to ld.so.conf, which
> > I'm trying to avoid. It would be nice to solve this generally
> > anyway.
> > 
> > Thoughts?
> >   
> 
> I'd say this is the sort of thing that has more application than just
> steam.
> 
> I'd just suggest a libpcre-debian package, which provides the .so via
> symlink and dependency mechanisms.
> 
> That way *if* anything happens in the future, we can just introduce
> blockers in the right place.
> 
> Then the applicable stuff depends on libpcre-debian for the forseeable
> future.
> 
> And this way, if debian do anything else magical, we can probably copy
> them and build a libpcre like they do for interop.
> 
> Essentially, the point here is to see debians libpcre is a competing
> implementation, even though we can locally pretend they're not at the
> technical level, it works as " conceptual model " for the problem we
> have.
> 

This sounds reasonable to me, that way we have pseudo-universal
handling of this for everything that needs it. The people who object to
adding stuff to support binary packages can just not install the
libpcre-debian package.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]

On Thu, 11 Aug 2016 11:05:00 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 11/08/16 10:57 AM, Mart Raudsepp wrote:
> > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich
> > Mueller:  
> >>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:  
> >>  
> >>>> Have you asked Debian why they are doing that?  
> >>  
> >>> I did find out but had since forgotten. Here it is:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10  
> >>
> >> So they are aware of the issue since 10 years, but chose not to fix
> >> it? Seriously, there's no good reason to dance to their tune
> >> then.  
> > 
> > It's not to dance to Debians tune, it's to dance to Valve tunes,
> > which happens to create its runtimes from Ubuntu packages.
> > I strongly believe that it's important to have such a use case as
> > Steam work problem-free in Gentoo. It's currently too messy, with
> > and without using steam runtime.
> > In the former case (using steam runtime), there are
> > incompatibilities between libraries found in the steam runtime, and
> > those that it doesn't include and assumes the system provides
> > (primarily mesa and deps); each steam runtime version you get to
> > hack around things by removing a small selection of libraries from
> > the steam runtime dir to get stuff working; a 1-2 month old upgrade
> > I haven't even managed to get to work yet on a more up to date
> > machine. In the latter case (forcing to not use steam runtime),
> > it's near impossible right now to get a set of 32bit binaries to
> > satisfy even steam client itself without lots of trial and error,
> > let alone some 32bit game.
> >   
> >>> I'm fine with putting it in libpcre-debian package as kentnl
> >>> suggested.  
> >>
> >> I still think that the libpcre.so.3 compatibility link shouldn't be
> >> installed in a generally visible location. Install it in a specific
> >> directory instead, and start your binary with a wrapper which will
> >> add that directory to LD_LIBRARY_PATH.  
> > 
> > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> > toolchain.eclass function does, except for pointing libpcre.so.3 to
> > libpcre.so.1 (so can't use that eclass function, but could just pre-
> > create one to $FILESDIR if it works)?
> > The important points should be:
> > 1) No compilation/linking done on Gentoo should possibly end up with
> > putting libpcre.so.3 in its DT_NEEDED
> > 2) libpcre.so should link to libpcre.so.1
> > 
> > If we can satisfy these, I don't see a reason to mess around with
> > some extra package.
> > Debian reasoning of having stuck with libpcre.so.3 historically is
> > sound as well, especially if upstream will never use that, given
> > libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2,
> > and given debians todays situation with this, I would also
> > technically choose not to change this, as things should migrate
> > over to PCRE2.
> > 
> > Mart
> 
> Wouldn't the most simple solution here would be to make a symlink for
> libpcre.so.3 within the local bindir for each Valve or whatever
> package that needs it?  This is a binary-package-supporting hack,
> might as well do it in the binary packages that need it.  You might
> still need to wrap the binary to set some environment stuff, not sure;
> either way it doesn't seem to make sense to make this a system-wide
> thing.

We don't package Steam itself and doing so isn't viable. We package
upstream's script for bootstrapping it under the user's HOME. As such,
there is nowhere to create such a symlink. It's not actually Steam
itself that requires libpcre.so.3 but (at least) one of its games. You
similarly can't create a symlink for each game because they also get
installed under HOME or some other user-defined location.

I have summed up the feedback. I have also considered that we don't
install the likes of libpng12.so.0 to a different location, even though
this is also there solely to satisfy pre-compiled binaries. We don't
even have a separate package for that though I will gladly compromise
on that point in this case. With all that in mind, I am going to
install to /lib using a libpcre-debian package. Sorry if you disagree
but since when do we all agree on anything? :)

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 5272 bytes --]

On 11/08/16 03:56 PM, James Le Cuirot wrote:
> On Thu, 11 Aug 2016 11:05:00 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
>> On 11/08/16 10:57 AM, Mart Raudsepp wrote:
>>> Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich
>>> Mueller:  
>>>>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:  
>>>>  
>>>>>> Have you asked Debian why they are doing that?  
>>>>  
>>>>> I did find out but had since forgotten. Here it is:
>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10  
>>>>
>>>> So they are aware of the issue since 10 years, but chose not to fix
>>>> it? Seriously, there's no good reason to dance to their tune
>>>> then.  
>>>
>>> It's not to dance to Debians tune, it's to dance to Valve tunes,
>>> which happens to create its runtimes from Ubuntu packages.
>>> I strongly believe that it's important to have such a use case as
>>> Steam work problem-free in Gentoo. It's currently too messy, with
>>> and without using steam runtime.
>>> In the former case (using steam runtime), there are
>>> incompatibilities between libraries found in the steam runtime, and
>>> those that it doesn't include and assumes the system provides
>>> (primarily mesa and deps); each steam runtime version you get to
>>> hack around things by removing a small selection of libraries from
>>> the steam runtime dir to get stuff working; a 1-2 month old upgrade
>>> I haven't even managed to get to work yet on a more up to date
>>> machine. In the latter case (forcing to not use steam runtime),
>>> it's near impossible right now to get a set of 32bit binaries to
>>> satisfy even steam client itself without lots of trial and error,
>>> let alone some 32bit game.
>>>   
>>>>> I'm fine with putting it in libpcre-debian package as kentnl
>>>>> suggested.  
>>>>
>>>> I still think that the libpcre.so.3 compatibility link shouldn't be
>>>> installed in a generally visible location. Install it in a specific
>>>> directory instead, and start your binary with a wrapper which will
>>>> add that directory to LD_LIBRARY_PATH.  
>>>
>>> Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
>>> toolchain.eclass function does, except for pointing libpcre.so.3 to
>>> libpcre.so.1 (so can't use that eclass function, but could just pre-
>>> create one to $FILESDIR if it works)?
>>> The important points should be:
>>> 1) No compilation/linking done on Gentoo should possibly end up with
>>> putting libpcre.so.3 in its DT_NEEDED
>>> 2) libpcre.so should link to libpcre.so.1
>>>
>>> If we can satisfy these, I don't see a reason to mess around with
>>> some extra package.
>>> Debian reasoning of having stuck with libpcre.so.3 historically is
>>> sound as well, especially if upstream will never use that, given
>>> libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2,
>>> and given debians todays situation with this, I would also
>>> technically choose not to change this, as things should migrate
>>> over to PCRE2.
>>>
>>> Mart
>>
>> Wouldn't the most simple solution here would be to make a symlink for
>> libpcre.so.3 within the local bindir for each Valve or whatever
>> package that needs it?  This is a binary-package-supporting hack,
>> might as well do it in the binary packages that need it.  You might
>> still need to wrap the binary to set some environment stuff, not sure;
>> either way it doesn't seem to make sense to make this a system-wide
>> thing.
> 
> We don't package Steam itself and doing so isn't viable. We package
> upstream's script for bootstrapping it under the user's HOME. As such,
> there is nowhere to create such a symlink. It's not actually Steam
> itself that requires libpcre.so.3 but (at least) one of its games. You
> similarly can't create a symlink for each game because they also get
> installed under HOME or some other user-defined location.
> 
> I have summed up the feedback. I have also considered that we don't
> install the likes of libpng12.so.0 to a different location, even though
> this is also there solely to satisfy pre-compiled binaries. We don't
> even have a separate package for that though I will gladly compromise
> on that point in this case. With all that in mind, I am going to
> install to /lib using a libpcre-debian package. Sorry if you disagree
> but since when do we all agree on anything? :)
> 
> Regards,
> 

The non-zero slotted libpng is different -- this is a compiled libpng
library that is provided to support binary packages as it the api and
abi has changed in newer ones.  A symlink of an identical library to
address a -name- change is totally different imo.

That said, I understand based on what's been described above how this
would be more easily handled at the system level rather than at an
individual package level (though I expect I would personally still
patch the upstream bootstrap script instead)

Installing the script to /lib though does not seem like the right way
to handle this; i know it works, but realistically this should be
installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you
still don't want to wrap the apps that need it then also install an
/etc/env.d/ file to add this dir to the LDPATH.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5784 bytes --]

On Thu, 11 Aug 2016 20:56:20 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> On Thu, 11 Aug 2016 11:05:00 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
> > On 11/08/16 10:57 AM, Mart Raudsepp wrote:  
> > > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich
> > > Mueller:    
> > >>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:    
> > >>    
> > >>>> Have you asked Debian why they are doing that?    
> > >>    
> > >>> I did find out but had since forgotten. Here it is:
> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10    
> > >>
> > >> So they are aware of the issue since 10 years, but chose not to fix
> > >> it? Seriously, there's no good reason to dance to their tune
> > >> then.    
> > > 
> > > It's not to dance to Debians tune, it's to dance to Valve tunes,
> > > which happens to create its runtimes from Ubuntu packages.
> > > I strongly believe that it's important to have such a use case as
> > > Steam work problem-free in Gentoo. It's currently too messy, with
> > > and without using steam runtime.
> > > In the former case (using steam runtime), there are
> > > incompatibilities between libraries found in the steam runtime, and
> > > those that it doesn't include and assumes the system provides
> > > (primarily mesa and deps); each steam runtime version you get to
> > > hack around things by removing a small selection of libraries from
> > > the steam runtime dir to get stuff working; a 1-2 month old upgrade
> > > I haven't even managed to get to work yet on a more up to date
> > > machine. In the latter case (forcing to not use steam runtime),
> > > it's near impossible right now to get a set of 32bit binaries to
> > > satisfy even steam client itself without lots of trial and error,
> > > let alone some 32bit game.
> > >     
> > >>> I'm fine with putting it in libpcre-debian package as kentnl
> > >>> suggested.    
> > >>
> > >> I still think that the libpcre.so.3 compatibility link shouldn't be
> > >> installed in a generally visible location. Install it in a specific
> > >> directory instead, and start your binary with a wrapper which will
> > >> add that directory to LD_LIBRARY_PATH.    
> > > 
> > > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> > > toolchain.eclass function does, except for pointing libpcre.so.3 to
> > > libpcre.so.1 (so can't use that eclass function, but could just pre-
> > > create one to $FILESDIR if it works)?
> > > The important points should be:
> > > 1) No compilation/linking done on Gentoo should possibly end up with
> > > putting libpcre.so.3 in its DT_NEEDED
> > > 2) libpcre.so should link to libpcre.so.1
> > > 
> > > If we can satisfy these, I don't see a reason to mess around with
> > > some extra package.
> > > Debian reasoning of having stuck with libpcre.so.3 historically is
> > > sound as well, especially if upstream will never use that, given
> > > libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2,
> > > and given debians todays situation with this, I would also
> > > technically choose not to change this, as things should migrate
> > > over to PCRE2.
> > > 
> > > Mart  
> > 
> > Wouldn't the most simple solution here would be to make a symlink for
> > libpcre.so.3 within the local bindir for each Valve or whatever
> > package that needs it?  This is a binary-package-supporting hack,
> > might as well do it in the binary packages that need it.  You might
> > still need to wrap the binary to set some environment stuff, not sure;
> > either way it doesn't seem to make sense to make this a system-wide
> > thing.  
> 
> We don't package Steam itself and doing so isn't viable. We package
> upstream's script for bootstrapping it under the user's HOME. As such,
> there is nowhere to create such a symlink. It's not actually Steam
> itself that requires libpcre.so.3 but (at least) one of its games. You
> similarly can't create a symlink for each game because they also get
> installed under HOME or some other user-defined location.

Well, how about you package a script to easily install Ubuntu on top of
Gentoo? That should make your system much more compliant with Valve's
idiocy than random symlinks.

> I have summed up the feedback. I have also considered that we don't
> install the likes of libpng12.so.0 to a different location, even though
> this is also there solely to satisfy pre-compiled binaries. We don't
> even have a separate package for that though I will gladly compromise
> on that point in this case. With all that in mind, I am going to
> install to /lib using a libpcre-debian package. Sorry if you disagree
> but since when do we all agree on anything? :)

libpng12.so.0 is an old version of a normal upstream library. It has
been released with that SONAME upstream, and it is globally meaningful.
libpcre.so.3 is some crappy Debian invention that's causing total
mayhem. It's not globally meaningful, it can collide with a future
upstream version and it messes up .so symlinks, as you already noticed.

If you are going to commit such crap into Gentoo ignoring people more
knowledgeable than you, please spare us the effort and open a QA bug
against it requesting that you remove it immediately. Thank you. Feel
free to also request revoking your commit rights for explicit ignoring
of QA feedback.

Now, seriously: Steam is a total pile of crap. We already had to hack
it to work-around completely braindead LD_LIBRARY_PATH override idiocy.
I don't see how much of a problem would it be to add an additional path
with crappy symlinks for it without polluting the whole system with
crap.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Thu, 11 Aug 2016 22:50:53 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > We don't package Steam itself and doing so isn't viable. We package
> > upstream's script for bootstrapping it under the user's HOME. As
> > such, there is nowhere to create such a symlink. It's not actually
> > Steam itself that requires libpcre.so.3 but (at least) one of its
> > games. You similarly can't create a symlink for each game because
> > they also get installed under HOME or some other user-defined
> > location.  
> 
> Well, how about you package a script to easily install Ubuntu on top
> of Gentoo? That should make your system much more compliant with
> Valve's idiocy than random symlinks.

With the exception of this, every game I've tried so far works with the
packages we have now. We're talking about one symlink here.

> > I have summed up the feedback. I have also considered that we don't
> > install the likes of libpng12.so.0 to a different location, even
> > though this is also there solely to satisfy pre-compiled binaries.
> > We don't even have a separate package for that though I will gladly
> > compromise on that point in this case. With all that in mind, I am
> > going to install to /lib using a libpcre-debian package. Sorry if
> > you disagree but since when do we all agree on anything? :)  
> 
> libpng12.so.0 is an old version of a normal upstream library. It has
> been released with that SONAME upstream, and it is globally
> meaningful. libpcre.so.3 is some crappy Debian invention that's
> causing total mayhem. It's not globally meaningful, it can collide
> with a future upstream version and it messes up .so symlinks, as you
> already noticed.

That future version would never happen. Even in the highly unlikely
event that this generation of the library would go beyond libpcre.so.2,
upstream would almost certainly skip 3 because of Debian.

It does not mess up symlinks if libpcre.so.1 is already there, which it
always would be. Let's stick to the facts.

> If you are going to commit such crap into Gentoo ignoring people more
> knowledgeable than you, please spare us the effort and open a QA bug
> against it requesting that you remove it immediately. Thank you. Feel
> free to also request revoking your commit rights for explicit ignoring
> of QA feedback.

That's an unfortunate tone. I feel I hold more respect for you than
most as I often find your ideas refreshingly innovative. I would
certainly bow to any serious concerns of real breakage but no one has
managed to provide a single demonstration of how this could actually
break anything. All anyone has managed to say is that it looks untidy
in their opinion.

> Now, seriously: Steam is a total pile of crap. We already had to hack
> it to work-around completely braindead LD_LIBRARY_PATH override
> idiocy. I don't see how much of a problem would it be to add an
> additional path with crappy symlinks for it without polluting the
> whole system with crap.

No one packages OpenGL libraries like we do so you can hardly blame
them for that. I'm not exactly Steam's biggest fan and I actually avoid
it where possible but it could surely be a lot worse.

Now I don't care for drama and I've got far more important things to
give a shit about so fine, I'll concede. Some restraint during our next
debate would be appreciated.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Thu, 11 Aug 2016 16:07:27 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> but realistically this should be
> installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you
> still don't want to wrap the apps that need it then also install an
> /etc/env.d/ file to add this dir to the LDPATH.

+1 to this. I was going to suggest something similar.

At least, because I'm still thinking in a view other than "steam", and
anticipating "Maybe we're going to do more of this"

If more than one binary application need more than one debian hack,
stuffing all the debian hacks in a special prefix that everyone can use
without polluting the main gentoo stuff is an advantage.

( And the separate dir makes it clear what the library is for and why
its there if anyone is trying to weed out some library problem that
still manages to happen despite our attempts )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mike Gilbert]

On Thu, Aug 11, 2016 at 4:50 PM, Michał Górny <mgorny@gentoo.org> wrote:
> If you are going to commit such crap into Gentoo ignoring people more
> knowledgeable than you, please spare us the effort and open a QA bug
> against it requesting that you remove it immediately. Thank you. Feel
> free to also request revoking your commit rights for explicit ignoring
> of QA feedback.

You need to chill the fuck out. This is not going to break all of
Gentoo, and your threats are incredibly rude.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mike Gilbert]

On Thu, Aug 11, 2016 at 5:34 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 11 Aug 2016 16:07:27 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>
>> but realistically this should be
>> installed to /usr/$(get_libdir)/debiancompat/ or similar, and if you
>> still don't want to wrap the apps that need it then also install an
>> /etc/env.d/ file to add this dir to the LDPATH.
>
> +1 to this. I was going to suggest something similar.
>
> At least, because I'm still thinking in a view other than "steam", and
> anticipating "Maybe we're going to do more of this"
>
> If more than one binary application need more than one debian hack,
> stuffing all the debian hacks in a special prefix that everyone can use
> without polluting the main gentoo stuff is an advantage.
>
> ( And the separate dir makes it clear what the library is for and why
> its there if anyone is trying to weed out some library problem that
> still manages to happen despite our attempts )

I also like the private libdir better than installing a symlink in a
"standard" libdir.

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Patrick McLean]

On Thu, 11 Aug 2016 22:50:53 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Thu, 11 Aug 2016 20:56:20 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
> > On Thu, 11 Aug 2016 11:05:00 -0400
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> >   
> > > On 11/08/16 10:57 AM, Mart Raudsepp wrote:    
> > > > Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich
> > > > Mueller:      
> > > >>>>>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:      
> > > >>      
> > > >>>> Have you asked Debian why they are doing that?      
> > > >>      
> > > >>> I did find out but had since forgotten. Here it is:
> > > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10      
> > > >>
> > > >> So they are aware of the issue since 10 years, but chose not
> > > >> to fix it? Seriously, there's no good reason to dance to their
> > > >> tune then.      
> > > > 
> > > > It's not to dance to Debians tune, it's to dance to Valve tunes,
> > > > which happens to create its runtimes from Ubuntu packages.
> > > > I strongly believe that it's important to have such a use case
> > > > as Steam work problem-free in Gentoo. It's currently too messy,
> > > > with and without using steam runtime.
> > > > In the former case (using steam runtime), there are
> > > > incompatibilities between libraries found in the steam runtime,
> > > > and those that it doesn't include and assumes the system
> > > > provides (primarily mesa and deps); each steam runtime version
> > > > you get to hack around things by removing a small selection of
> > > > libraries from the steam runtime dir to get stuff working; a
> > > > 1-2 month old upgrade I haven't even managed to get to work yet
> > > > on a more up to date machine. In the latter case (forcing to
> > > > not use steam runtime), it's near impossible right now to get a
> > > > set of 32bit binaries to satisfy even steam client itself
> > > > without lots of trial and error, let alone some 32bit game.
> > > >       
> > > >>> I'm fine with putting it in libpcre-debian package as kentnl
> > > >>> suggested.      
> > > >>
> > > >> I still think that the libpcre.so.3 compatibility link
> > > >> shouldn't be installed in a generally visible location.
> > > >> Install it in a specific directory instead, and start your
> > > >> binary with a wrapper which will add that directory to
> > > >> LD_LIBRARY_PATH.      
> > > > 
> > > > Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> > > > toolchain.eclass function does, except for pointing
> > > > libpcre.so.3 to libpcre.so.1 (so can't use that eclass
> > > > function, but could just pre- create one to $FILESDIR if it
> > > > works)? The important points should be:
> > > > 1) No compilation/linking done on Gentoo should possibly end up
> > > > with putting libpcre.so.3 in its DT_NEEDED
> > > > 2) libpcre.so should link to libpcre.so.1
> > > > 
> > > > If we can satisfy these, I don't see a reason to mess around
> > > > with some extra package.
> > > > Debian reasoning of having stuck with libpcre.so.3 historically
> > > > is sound as well, especially if upstream will never use that,
> > > > given libpcre2.so.x or however they soname pcre2-10+. Also,
> > > > given PCRE2, and given debians todays situation with this, I
> > > > would also technically choose not to change this, as things
> > > > should migrate over to PCRE2.
> > > > 
> > > > Mart    
> > > 
> > > Wouldn't the most simple solution here would be to make a symlink
> > > for libpcre.so.3 within the local bindir for each Valve or
> > > whatever package that needs it?  This is a
> > > binary-package-supporting hack, might as well do it in the binary
> > > packages that need it.  You might still need to wrap the binary
> > > to set some environment stuff, not sure; either way it doesn't
> > > seem to make sense to make this a system-wide thing.    
> > 
> > We don't package Steam itself and doing so isn't viable. We package
> > upstream's script for bootstrapping it under the user's HOME. As
> > such, there is nowhere to create such a symlink. It's not actually
> > Steam itself that requires libpcre.so.3 but (at least) one of its
> > games. You similarly can't create a symlink for each game because
> > they also get installed under HOME or some other user-defined
> > location.  
> 
> Well, how about you package a script to easily install Ubuntu on top
> of Gentoo? That should make your system much more compliant with
> Valve's idiocy than random symlinks.
> 
> If you are going to commit such crap into Gentoo ignoring people more
> knowledgeable than you, please spare us the effort and open a QA bug
> against it requesting that you remove it immediately. Thank you. Feel
> free to also request revoking your commit rights for explicit ignoring
> of QA feedback.
>

Think of it as a package, install it if you want steam games to work on
your machine, if you don't care and don't want that crap on your
system, then don't install it. It's not like there is a shortage of
packages that install crappy crap on your system...

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Thu, 11 Aug 2016 17:27:14 -0700
Patrick McLean <chutzpah@gentoo.org> wrote:

>  It's not like there is a shortage of
> packages that install crappy crap on your system...

In this instance I agree that we're kinda stressing about the wrong
thing.

But I can't support that reasoning.

"There is bad stuff in tree so why not have more" is not a great line
of reasoning.

We want things to be *better*, we should shy away from that reasoning.

The *reason* here is "user choice".

As much as Gentoo developers may have problems with steam, user-choice
orientation dictates we should at least consider supporting it in some
regard, and if we can do so without affecting the people who don't want
steam, we should also strive to do that.

And we *can*. 

That's why its better as an independent thing, not as core mechanics in
libpcre.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 18:00, kirjutas Mike Gilbert:
> On Thu, Aug 11, 2016 at 5:34 PM, Kent Fredric <kentnl@gentoo.org>
> wrote:
> > On Thu, 11 Aug 2016 16:07:27 -0400
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> > 
> > > but realistically this should be
> > > installed to /usr/$(get_libdir)/debiancompat/ or similar, and if
> > > you
> > > still don't want to wrap the apps that need it then also install
> > > an
> > > /etc/env.d/ file to add this dir to the LDPATH.
> > 
> > +1 to this. I was going to suggest something similar.
> > 
> > At least, because I'm still thinking in a view other than "steam",
> > and
> > anticipating "Maybe we're going to do more of this"
> > 
> > If more than one binary application need more than one debian hack,
> > stuffing all the debian hacks in a special prefix that everyone can
> > use
> > without polluting the main gentoo stuff is an advantage.
> > 
> > ( And the separate dir makes it clear what the library is for and
> > why
> > its there if anyone is trying to weed out some library problem that
> > still manages to happen despite our attempts )
> 
> I also like the private libdir better than installing a symlink in a
> "standard" libdir.

The question is really why, still.
I only see some sort of tidyness arguments, but it's not exactly tidy
to clobber ld.so.conf either, so I don't consider this a real argument.

If you install a proprietary package from their .tar.bz2 or Loki .sh
installer or whatever, the user will not know to install some libpcre-
debian package.
Also, again, PCRE2 is there. Soon dev-libs/libpcre:3 (libpcre-8.*) is
primarily a binary package satisfier anyways, so why not just satisfy
libpcre.so.3 while at it. Funny fact - we have it in SLOT=3 too :)

Ultimately I don't care personally as a gentoo user, as I will know to
install this useless symlink package. Maybe, if I remember. And only
because of a 10+ thread. But our users are uselessly bothered when they
actually need it by something.
They ought to be able to choose to not care, and have shit working out
of the box. This is providing a very important choice, in the spirit of
Gentoo.


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/11/2016 07:32 PM, Kent Fredric wrote:
> On Thu, 11 Aug 2016 17:27:14 -0700
> Patrick McLean <chutzpah@gentoo.org> wrote:
>
>>  It's not like there is a shortage of
>> packages that install crappy crap on your system...
>
> In this instance I agree that we're kinda stressing about the wrong
> thing.
>
> But I can't support that reasoning.
>
> "There is bad stuff in tree so why not have more" is not a great line
> of reasoning.
>
> We want things to be *better*, we should shy away from that reasoning.
>
> The *reason* here is "user choice".
>
> As much as Gentoo developers may have problems with steam, user-choice
> orientation dictates we should at least consider supporting it in some
> regard, and if we can do so without affecting the people who don't want
> steam, we should also strive to do that.
>
> And we *can*.
>
> That's why its better as an independent thing, not as core mechanics in
> libpcre.
>

One possible solution, is to realize that everyone is right from their 
perspective. OK. Then how do *we* find an acceptable solution set? Well, 
this is not the first time and it's occurring more and more frequently 
in gentoo, from my perspective, that our ying-n-yang of secure vs 
innovation is pulling the devs apart.

1. We do need an extraordinarily (think hardened++) secure gentoo, as 
the nefarious activities of interlopers is becoming an avalanche on 
computing and networking (Think Zener (or avalance) diode). [1]
A few quick and easy, stage-4 offerings for common needs, would be a 
strong recruiting tool for gentoo. ymmv.


[1] https://en.wikipedia.org/wiki/Avalanche_diode

Certainly QA is part of that solution, and those folks are 100% correct.

2. Gentoo needs to have a version (jentoo?) so that we can return  to 
raw innovation, of anything and everything any technoid wants to pursue.
To me, that was and is the heart and soul of gentoo; but that postulate 
alone wreaks of multifaceted danger. (danger Will Robinson, danger!). 
Still my needs and heart is with these innovative folks, 100%, and yes 
it is due to my new found addiction to all things clusterd.


So, how about we use (VMs/Container/unikernels/embedded/<and many more 
approaches>) to allow both to coexist on the same hardware? Now, whether
Gentoo(hardened) is the main host and Jentoo(the latest innovation) is 
the VM  or vice-versa, remains to be explored and proven and provided as 
a choice. Deeply embedded, hardened-gentoo, located on a usb stick, does 
appeal to many different uses and it can be quickly unplugged by the 
local admin, as an added fail-safe feature. Choice is preeminent, imho.


I'd like to see Jentoo, become the most innovative platform in the 
entire FOSS world, as gentoo once was.  For now, they (Gentoo and 
Jentoo) could be run on different (hardware) systems and combined later, 
when viable mechanisms are proposed, tested and vetted. This thread of 
consternation only servers to 'yet again' validate both needs. Jentoo 
could live out of an alternative repo, and the rules for putting codes 
in there, are managed by the devs that favor innovation over 
constriction. In fact, we could also experiment with an open source 
alternative (gitlab?) in lieu of github (just a thought, do not get your 
panties in a bunch over this)?


Gentoo, does need a 'tight-assed', secure and reliability first mantra 
to move forward to serve the computational worlds needs. Security is at 
a breaking point, imho; hacker news has a posting about systemd and 
buntu in full meltdown related to (server)clusters. Furthermore, 
nation-states have a vesting interest in taxing the productive for a 
variety of reasons, and network/computing/communications instability is 
the new 'cold war' where excessive taxes, robber-barron greed, and 
globalization are converging towards war(3). So do not look to 
governments or the globalist to prevent war. I'm not certain that gentoo 
can prevent this, but it's worth a little effort, no?


If we can make a secure peace with both the innovative and the secure 
camps, within Gentoo (and Jentoo), then perhaps the computational world 
will follow our lead. Vendors (greeds) are going to plunge us into WW3, 
if folks do not 'wise up' and 'pull together'.

(also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?

(peace && hth),
James

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On Fri, 12 Aug 2016 09:12:22 -0500
james <garftd@verizon.net> wrote:

> (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?
> 
> (peace && hth),
> James

Way outside the scope needed here. However we pull off Zhenchoo, its
going to be built on top of portage and our package management with
extra bling.

That's what is necessary to empower people with "ready built" machines
to customize it in the direction of a "natural gentoo install"

All this converstation details is:

- Is a given technique good
- Can it be installed in tree without breaking things
- How do we do that
- Is there a place we can do it where the problem is isolated to a
  narrow spectrum of users to limit potential fallout
- Is this a "Put warning bells on it and let users blow off their own
  feet and then don't do it by default"[1] thing.
- Can this be a "Just package.mask the problem on hardened" thing.

All of those can be combined in some way to get and end result by
whoever ships the stage 4 the way they want to do it. They can use an
overlay if they want.

Nothing is stopping them :)

Other than themselves of course.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/12/2016 10:39 AM, Kent Fredric wrote:
> On Fri, 12 Aug 2016 09:12:22 -0500
> james <garftd@verizon.net> wrote:
>
>> (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?
>>
>> (peace && hth),
>> James
>
> Way outside the scope needed here. However we pull off Zhenchoo, its
> going to be built on top of portage and our package management with
> extra bling.
>
> That's what is necessary to empower people with "ready built" machines
> to customize it in the direction of a "natural gentoo install"
>
> All this converstation details is:
>
> - Is a given technique good
> - Can it be installed in tree without breaking things
> - How do we do that
> - Is there a place we can do it where the problem is isolated to a
>   narrow spectrum of users to limit potential fallout
> - Is this a "Put warning bells on it and let users blow off their own
>   feet and then don't do it by default"[1] thing.
> - Can this be a "Just package.mask the problem on hardened" thing.
>
> All of those can be combined in some way to get and end result by
> whoever ships the stage 4 the way they want to do it. They can use an
> overlay if they want.
>
> Nothing is stopping them :)
>
> Other than themselves of course.
>

That simple huh?

Ok, show us a solution based on your dashed items, for the current
Valve/Steam/issues, and wrap up those very cool aforementioned games 
into a stage 4?

I'd even settle for a liveDVD on that..... Remember::
Nothing is stopping you, other than yourself of course....


James

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

On 12/08/16 18:40, james wrote:
> On 08/12/2016 10:39 AM, Kent Fredric wrote:
>> On Fri, 12 Aug 2016 09:12:22 -0500
>> james <garftd@verizon.net> wrote:
>>
>>> (also, I'm not hung up on 'Jentoo' as a name; perhaps 'Gintoo'?
>>>
>>> (peace && hth),
>>> James
>>
>> Way outside the scope needed here. However we pull off Zhenchoo, its
>> going to be built on top of portage and our package management with
>> extra bling.
>>
>> That's what is necessary to empower people with "ready built" machines
>> to customize it in the direction of a "natural gentoo install"
>>
>> All this converstation details is:
>>
>> - Is a given technique good
>> - Can it be installed in tree without breaking things
>> - How do we do that
>> - Is there a place we can do it where the problem is isolated to a
>>   narrow spectrum of users to limit potential fallout
>> - Is this a "Put warning bells on it and let users blow off their own
>>   feet and then don't do it by default"[1] thing.
>> - Can this be a "Just package.mask the problem on hardened" thing.
>>
>> All of those can be combined in some way to get and end result by
>> whoever ships the stage 4 the way they want to do it. They can use an
>> overlay if they want.
>>
>> Nothing is stopping them :)
>>
>> Other than themselves of course.
>>
>
> That simple huh?
>
> Ok, show us a solution based on your dashed items, for the current
> Valve/Steam/issues, and wrap up those very cool aforementioned games
> into a stage 4?
>
> I'd even settle for a liveDVD on that..... Remember::
> Nothing is stopping you, other than yourself of course....
>
>
> James
>
>
Kent's suggestions are quite valid, and indeed a good starting point for
anyone wishing to push their ideas forward (deliberately avoiding no
names at this point).

I can say that Kent is doing a stirling job supporting the Perl project
with an enormous amount of effort in keeping Perl current and valid for
the Gentoo distribution, and wouldn't be best placed to add to his
already full workload - we are all volunteers at the end of the day ..
or did someone forget that.

I regret to say, although it's a well-known problem .. that the Gentoo
bike-shed is never ever going to fall down - as the layers of paint
applied will grossly outlive the materials it might once have been built
from ... Perhaps someone might like to address the problem of the
nuclear reactor which will otherwise never ever be functional ... ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Fri, 12 Aug 2016 12:40:38 -0500
james <garftd@verizon.net> wrote:

> Ok, show us a solution based on your dashed items

That's not what were doing here.

We have a bunch of different solutions with different trade-offs, and
whatever happens has to live with everything else.

And so we're discussing them, working out which one we're going to do.

> Nothing is stopping you, other than yourself of course....

My point is more, clearly, you're the most motivated about this, surely
this means you're in more of a position to do something about it.

Its not on my list of immediate tasks, because a) It doesn't directly
interest me b) I have other pressing things to stress over.

I'm preoccupied with making things better within our current capacity
and features.

I don't have the resources to stretch our feature set and make things
more reliable in Gentoo at the same time :)

hth :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Rich Freeman]

On Fri, Aug 12, 2016 at 1:48 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>
> I regret to say, although it's a well-known problem .. that the Gentoo
> bike-shed is never ever going to fall down - as the layers of paint
> applied will grossly outlive the materials it might once have been built
> from ... Perhaps someone might like to address the problem of the
> nuclear reactor which will otherwise never ever be functional ... ;)
>

Bikeshedding is only a problem if you let it be one.

Gentoo does not require unanimous consensus to get things done.  If
you choose to wait for it, and then complain about bikeshedding, then
YOU are the problem.

If I were James I would:

1.  Consider the advice given and propose the best way forward.
Indicate that I intend to commit the changes to the Gentoo repo in 48h
if there are no objections raised by QA or to Council.
2.  If there are no objections raised to Council or by QA then go
ahead with the commits, unless personally convinced by any further
arguments.
3.  If an objection was raised to QA, then comply with it for now, and
if in disagreement first work with QA, and appeal to Council if
necessary.
4.  If somebody appeals to Council, then let them make their case, and
offer my own, and await a decision.

If you do the above you'll never get in trouble, and you've basically
put the ball in somebody else's court if they want to hold you up.
Usually you won't delay your change by more than 48h, and if you do it
won't be by more than a month, unless the Council overrides you (in
which case you're "stuck" though presumably they would have good
reasons for doing so).

Some mistakes I see people make all the time:
1.  Give up as soon as a few devs make vocal complaints.  This is not
a shouting match.  The person with the most thread posts doesn't
automatically win the argument.
2.  Wait until everybody agrees.  While there are things everybody
agrees on, there aren't many of them.  I'm not sure the last sentence
even falls into that list of things everybody agrees on.  :)
3.  Plow forward without giving some time for appeals.  This can lead
to revert wars and such.
4.  Ignore official QA notices.  If a member of QA notifies you that
QA is taking action, you must comply until you resolve the issue with
QA or by appeal.
5.  Fail to work with QA.  The fact that a random QA member takes an
action doesn't mean that all of QA is necessarily behind it.  You may
find the issue resolved by spending 30 seconds on IRC.  The QA lead is
responsible to deal with these kinds of issues.
6.  Fail to let the Council clear roadblocks.  If you're trying to do
something, and you feel that something is blocking you, the Council
can help resolve that.

Devs get frustrated by bikeshedding because they're imposing rules and
limitations upon themselves that aren't actually community rules.  You
don't have to give up just because a few devs complain.  You ought to
listen, and if it is really controversial push for a decision.
However, strictly speaking if you have commit rights to the tree and
aren't violating a documented policy, then the onus is on others to
stop you, not for you to obtain permission to do something.  You
shouldn't abuse that, and hence I suggest giving people time to lodge
formal objections.  However, if you care about getting something done
it is completely fair to force those who wish to impede you to step up
and do the work to actively block you.  Devs don't have to prove the
"innocence" of each commit.

-- 
Rich

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 3144 bytes --]

On 08/10/2016 10:53 PM, Kent Fredric wrote:
> On Thu, 11 Aug 2016 00:10:53 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
>> Hello all,
>>
>> We, like almost everyone else and presumably upstream, install PCRE 8
>> as libpcre.so.1. Debian, for reasons best known to themselves, install
>> it as libpcre.so.3. With Ubuntu still being the most widely accepted
>> "standard" Linux desktop, this presents a problem when dealing with
>> pre-compiled binaries.
>>
>> I have been working on a script to replace the rather lacking
>> steam-games-meta ebuild (see steam-overlay). I'm very excited about
>> releasing it soon as I think it is a major step forwards in our
>> ability to easily run Steam without the official Ubuntu-based runtime.
>>
>> Before I put it out there, I'd like to get Alien Isolation working
>> properly. It links to libpcre.so.3. Hacking the binary might work but
>> this isn't ideal and not always an option as some games use Valve's
>> anti-cheat system, which is ruthless.
>>
>> I have found that creating a symlink in /usr/lib that points
>> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
>> automatically creates another symlink from /usr/lib/libpcre.so.1 to
>> libpcre.so.3. If you create the first symlink in /lib instead then the
>> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
>> location is therefore probably preferable.
>>
>> Would anyone have any issue with adding this to our libpcre package? I
>> don't foresee any problems. libpcre.so would obviously still point to
>> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
>> as upstream have released PCRE2 as libpcre2, effectively an entirely
>> separate library.
>>
>> I could create a Steam-specific package for this but that would mean
>> adding some additional Steam-specific location to ld.so.conf, which
>> I'm trying to avoid. It would be nice to solve this generally anyway.
>>
>> Thoughts?
>>
> 
> I'd say this is the sort of thing that has more application than just
> steam.
> 
> I'd just suggest a libpcre-debian package, which provides the .so via
> symlink and dependency mechanisms.
> 
> That way *if* anything happens in the future, we can just introduce
> blockers in the right place.
> 
> Then the applicable stuff depends on libpcre-debian for the forseeable
> future.
> 
> And this way, if debian do anything else magical, we can probably copy
> them and build a libpcre like they do for interop.
> 
> Essentially, the point here is to see debians libpcre is a competing
> implementation, even though we can locally pretend they're not at the
> technical level, it works as " conceptual model " for the problem we
> have.
> 
Bam, +1 from me. It technically adds package "bloat", but Steam already
requires a lot of finagling. Requiring a package that's explicitly
designed to mimic Debian makes it easier to figure out what's wrong,
should any bugs crop up.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 3352 bytes --]

On 08/11/2016 06:19 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 11.08.2016 kell 18:00, kirjutas Mike Gilbert:
>> On Thu, Aug 11, 2016 at 5:34 PM, Kent Fredric <kentnl@gentoo.org>
>> wrote:
>>> On Thu, 11 Aug 2016 16:07:27 -0400
>>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>>
>>>> but realistically this should be
>>>> installed to /usr/$(get_libdir)/debiancompat/ or similar, and if
>>>> you
>>>> still don't want to wrap the apps that need it then also install
>>>> an
>>>> /etc/env.d/ file to add this dir to the LDPATH.
>>>
>>> +1 to this. I was going to suggest something similar.
>>>
>>> At least, because I'm still thinking in a view other than "steam",
>>> and
>>> anticipating "Maybe we're going to do more of this"
>>>
>>> If more than one binary application need more than one debian hack,
>>> stuffing all the debian hacks in a special prefix that everyone can
>>> use
>>> without polluting the main gentoo stuff is an advantage.
>>>
>>> ( And the separate dir makes it clear what the library is for and
>>> why
>>> its there if anyone is trying to weed out some library problem that
>>> still manages to happen despite our attempts )
>>
>> I also like the private libdir better than installing a symlink in a
>> "standard" libdir.
> 
> The question is really why, still.
> I only see some sort of tidyness arguments, but it's not exactly tidy
> to clobber ld.so.conf either, so I don't consider this a real argument.
> 
> If you install a proprietary package from their .tar.bz2 or Loki .sh
> installer or whatever, the user will not know to install some libpcre-
> debian package.
> Also, again, PCRE2 is there. Soon dev-libs/libpcre:3 (libpcre-8.*) is
> primarily a binary package satisfier anyways, so why not just satisfy
> libpcre.so.3 while at it. Funny fact - we have it in SLOT=3 too :)
> 
> Ultimately I don't care personally as a gentoo user, as I will know to
> install this useless symlink package. Maybe, if I remember. And only
> because of a 10+ thread. But our users are uselessly bothered when they
> actually need it by something.
> They ought to be able to choose to not care, and have shit working out
> of the box. This is providing a very important choice, in the spirit of
> Gentoo.
> 
> 
> Mart
> 
We normally have our differences but I have to agree here. Getting
proprietary stuff to work at all is a pain; being able to simply not
care and "just make it work" would be great. I think we can do it no
matter where we choose to install things. iirc the steam-meta package
already includes a wrapper.

Given that Valve only promises support on Ubuntu (and SteamOS which is
basically Ubuntu), we should probably use a Debian/Ubuntu-specific
compat dir so we can address all future kludges instead of just PCRE.

But really, we should be able to make it so users can `emerge -a steam`,
wait a few minutes, and be able to type "steam" into a terminal or run
dialog and it "just works". Skype does it; I don't see why Steam can't,
unless there's a licensing problem.

(This is my perspective as a user who begrudgingly uses Skype and Steam,
and has historically had more trouble from Steam)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[james]

On 08/11/2016 11:32 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 11.08.2016 kell 11:23, kirjutas james:
>> Whilst devs are discussing the future of Valve's offerings on
>> gentoo,
>> it'd be wise to consider the effects of "Vulcan" as it is FOSS where
>> all
>> video card vendors can inter-operate with multiple game vendors.
>> Vulcan
>> will impact  those gaming codes, as Vulcan seems to be the clear
>> pathway
>> forward for Valve related to Open Source communities [1 3].
>
> I have no idea what Vulcan is, besides the race in Star Trek or Roman
> god, but Vulkan is tracked in https://bugs.gentoo.org/574886 and Intel
> support in https://bugs.gentoo.org/580148
>
> I was going to look into it as well on basis of Intel Vulkan with
> dota2, but on that machine Steam doesn't even work anymore due to
> https://github.com/ValveSoftware/steam-for-linux/issues/4537
> so got rather demotivated. Basically a case where having a fully
> working setup without steam runtime should also fix it. Current main
> machine has Radeon Evergreen and so no current Vulkan implementation to
> play with.
>
>
> Mart


All of this is a moving target, for sure. This is dated but here
is some more info. Surely there will be consolidation and back-porting
of codes to make the linux vulcan drivers more useful to the FOSS 
communities, I hope. I'm just not sure when this will happen and I would 
not be able to offer guidance, hence, I have filed no bugs on Vulcan. 
I'm not really up on the latest of what's working either.

My main issue it to use the GPU resources of all video cards, with 
compilers and on clusters, at some point, in the future

http://www.phoronix.com/scan.php?page=search&q=Vulkan


hth,
James