* [gentoo-dev] libpcre.so.3 - Compatibility with Debian @ 2016-08-10 23:10 James Le Cuirot 2016-08-11 5:53 ` Kent Fredric ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: James Le Cuirot @ 2016-08-10 23:10 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-10 23:10 [gentoo-dev] libpcre.so.3 - Compatibility with Debian James Le Cuirot @ 2016-08-11 5:53 ` Kent Fredric 2016-08-11 15:41 ` Mike Gilbert ` (2 more replies) 2016-08-11 9:43 ` Ulrich Mueller 2016-08-11 16:23 ` james 2 siblings, 3 replies; 38+ messages in thread From: Kent Fredric @ 2016-08-11 5:53 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 5:53 ` Kent Fredric @ 2016-08-11 15:41 ` Mike Gilbert 2016-08-11 18:57 ` Patrick McLean 2016-08-18 5:45 ` Daniel Campbell 2 siblings, 0 replies; 38+ messages in thread From: Mike Gilbert @ 2016-08-11 15:41 UTC (permalink / raw To: Gentoo Dev 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 5:53 ` Kent Fredric 2016-08-11 15:41 ` Mike Gilbert @ 2016-08-11 18:57 ` Patrick McLean 2016-08-18 5:45 ` Daniel Campbell 2 siblings, 0 replies; 38+ messages in thread From: Patrick McLean @ 2016-08-11 18:57 UTC (permalink / raw To: Kent Fredric; +Cc: gentoo-dev 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 5:53 ` Kent Fredric 2016-08-11 15:41 ` Mike Gilbert 2016-08-11 18:57 ` Patrick McLean @ 2016-08-18 5:45 ` Daniel Campbell 2 siblings, 0 replies; 38+ messages in thread From: Daniel Campbell @ 2016-08-18 5:45 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-10 23:10 [gentoo-dev] libpcre.so.3 - Compatibility with Debian James Le Cuirot 2016-08-11 5:53 ` Kent Fredric @ 2016-08-11 9:43 ` Ulrich Mueller 2016-08-11 10:11 ` James Le Cuirot 2016-08-11 16:23 ` james 2 siblings, 1 reply; 38+ messages in thread From: Ulrich Mueller @ 2016-08-11 9:43 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 9:43 ` Ulrich Mueller @ 2016-08-11 10:11 ` James Le Cuirot 2016-08-11 10:56 ` Ulrich Mueller 0 siblings, 1 reply; 38+ messages in thread From: James Le Cuirot @ 2016-08-11 10:11 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 10:11 ` James Le Cuirot @ 2016-08-11 10:56 ` Ulrich Mueller 2016-08-11 11:20 ` James Le Cuirot 2016-08-11 14:57 ` Mart Raudsepp 0 siblings, 2 replies; 38+ messages in thread From: Ulrich Mueller @ 2016-08-11 10:56 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 10:56 ` Ulrich Mueller @ 2016-08-11 11:20 ` James Le Cuirot 2016-08-11 11:49 ` Kristian Fiskerstrand 2016-08-11 12:04 ` Ulrich Mueller 2016-08-11 14:57 ` Mart Raudsepp 1 sibling, 2 replies; 38+ messages in thread From: James Le Cuirot @ 2016-08-11 11:20 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 11:20 ` James Le Cuirot @ 2016-08-11 11:49 ` Kristian Fiskerstrand 2016-08-11 12:04 ` Ulrich Mueller 1 sibling, 0 replies; 38+ messages in thread From: Kristian Fiskerstrand @ 2016-08-11 11:49 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 11:20 ` James Le Cuirot 2016-08-11 11:49 ` Kristian Fiskerstrand @ 2016-08-11 12:04 ` Ulrich Mueller 2016-08-11 12:13 ` Rich Freeman 1 sibling, 1 reply; 38+ messages in thread From: Ulrich Mueller @ 2016-08-11 12:04 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 12:04 ` Ulrich Mueller @ 2016-08-11 12:13 ` Rich Freeman 0 siblings, 0 replies; 38+ messages in thread From: Rich Freeman @ 2016-08-11 12:13 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 10:56 ` Ulrich Mueller 2016-08-11 11:20 ` James Le Cuirot @ 2016-08-11 14:57 ` Mart Raudsepp 2016-08-11 15:03 ` Ciaran McCreesh 2016-08-11 15:05 ` Ian Stakenvicius 1 sibling, 2 replies; 38+ messages in thread From: Mart Raudsepp @ 2016-08-11 14:57 UTC (permalink / raw To: gentoo-dev Ü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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 14:57 ` Mart Raudsepp @ 2016-08-11 15:03 ` Ciaran McCreesh 2016-08-11 15:05 ` Ian Stakenvicius 1 sibling, 0 replies; 38+ messages in thread From: Ciaran McCreesh @ 2016-08-11 15:03 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 14:57 ` Mart Raudsepp 2016-08-11 15:03 ` Ciaran McCreesh @ 2016-08-11 15:05 ` Ian Stakenvicius 2016-08-11 15:15 ` Mart Raudsepp 2016-08-11 19:56 ` James Le Cuirot 1 sibling, 2 replies; 38+ messages in thread From: Ian Stakenvicius @ 2016-08-11 15:05 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 15:05 ` Ian Stakenvicius @ 2016-08-11 15:15 ` Mart Raudsepp 2016-08-11 19:56 ` James Le Cuirot 1 sibling, 0 replies; 38+ messages in thread From: Mart Raudsepp @ 2016-08-11 15:15 UTC (permalink / raw To: gentoo-dev Ü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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 15:05 ` Ian Stakenvicius 2016-08-11 15:15 ` Mart Raudsepp @ 2016-08-11 19:56 ` James Le Cuirot 2016-08-11 20:07 ` Ian Stakenvicius 2016-08-11 20:50 ` Michał Górny 1 sibling, 2 replies; 38+ messages in thread From: James Le Cuirot @ 2016-08-11 19:56 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 19:56 ` James Le Cuirot @ 2016-08-11 20:07 ` Ian Stakenvicius 2016-08-11 21:34 ` Kent Fredric 2016-08-11 20:50 ` Michał Górny 1 sibling, 1 reply; 38+ messages in thread From: Ian Stakenvicius @ 2016-08-11 20:07 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 20:07 ` Ian Stakenvicius @ 2016-08-11 21:34 ` Kent Fredric 2016-08-11 22:00 ` Mike Gilbert 0 siblings, 1 reply; 38+ messages in thread From: Kent Fredric @ 2016-08-11 21:34 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 21:34 ` Kent Fredric @ 2016-08-11 22:00 ` Mike Gilbert 2016-08-12 1:19 ` Mart Raudsepp 0 siblings, 1 reply; 38+ messages in thread From: Mike Gilbert @ 2016-08-11 22:00 UTC (permalink / raw To: Gentoo Dev 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 22:00 ` Mike Gilbert @ 2016-08-12 1:19 ` Mart Raudsepp 2016-08-18 6:06 ` Daniel Campbell 0 siblings, 1 reply; 38+ messages in thread From: Mart Raudsepp @ 2016-08-12 1:19 UTC (permalink / raw To: gentoo-dev Ü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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 1:19 ` Mart Raudsepp @ 2016-08-18 6:06 ` Daniel Campbell 0 siblings, 0 replies; 38+ messages in thread From: Daniel Campbell @ 2016-08-18 6:06 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 19:56 ` James Le Cuirot 2016-08-11 20:07 ` Ian Stakenvicius @ 2016-08-11 20:50 ` Michał Górny 2016-08-11 21:30 ` James Le Cuirot ` (2 more replies) 1 sibling, 3 replies; 38+ messages in thread From: Michał Górny @ 2016-08-11 20:50 UTC (permalink / raw To: James Le Cuirot; +Cc: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 20:50 ` Michał Górny @ 2016-08-11 21:30 ` James Le Cuirot 2016-08-11 21:55 ` Mike Gilbert 2016-08-12 0:27 ` Patrick McLean 2 siblings, 0 replies; 38+ messages in thread From: James Le Cuirot @ 2016-08-11 21:30 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 20:50 ` Michał Górny 2016-08-11 21:30 ` James Le Cuirot @ 2016-08-11 21:55 ` Mike Gilbert 2016-08-12 0:27 ` Patrick McLean 2 siblings, 0 replies; 38+ messages in thread From: Mike Gilbert @ 2016-08-11 21:55 UTC (permalink / raw To: Gentoo Dev; +Cc: James Le Cuirot 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 20:50 ` Michał Górny 2016-08-11 21:30 ` James Le Cuirot 2016-08-11 21:55 ` Mike Gilbert @ 2016-08-12 0:27 ` Patrick McLean 2016-08-12 0:32 ` Kent Fredric 2 siblings, 1 reply; 38+ messages in thread From: Patrick McLean @ 2016-08-12 0:27 UTC (permalink / raw To: Michał Górny; +Cc: gentoo-dev, James Le Cuirot 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... ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 0:27 ` Patrick McLean @ 2016-08-12 0:32 ` Kent Fredric 2016-08-12 14:12 ` james 0 siblings, 1 reply; 38+ messages in thread From: Kent Fredric @ 2016-08-12 0:32 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 0:32 ` Kent Fredric @ 2016-08-12 14:12 ` james 2016-08-12 15:39 ` Kent Fredric 0 siblings, 1 reply; 38+ messages in thread From: james @ 2016-08-12 14:12 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 14:12 ` james @ 2016-08-12 15:39 ` Kent Fredric 2016-08-12 17:40 ` james 0 siblings, 1 reply; 38+ messages in thread From: Kent Fredric @ 2016-08-12 15:39 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 15:39 ` Kent Fredric @ 2016-08-12 17:40 ` james 2016-08-12 17:48 ` M. J. Everitt 2016-08-12 17:55 ` Kent Fredric 0 siblings, 2 replies; 38+ messages in thread From: james @ 2016-08-12 17:40 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 17:40 ` james @ 2016-08-12 17:48 ` M. J. Everitt 2016-08-12 22:36 ` Rich Freeman 2016-08-12 17:55 ` Kent Fredric 1 sibling, 1 reply; 38+ messages in thread From: M. J. Everitt @ 2016-08-12 17:48 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 17:48 ` M. J. Everitt @ 2016-08-12 22:36 ` Rich Freeman 0 siblings, 0 replies; 38+ messages in thread From: Rich Freeman @ 2016-08-12 22:36 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-12 17:40 ` james 2016-08-12 17:48 ` M. J. Everitt @ 2016-08-12 17:55 ` Kent Fredric 1 sibling, 0 replies; 38+ messages in thread From: Kent Fredric @ 2016-08-12 17:55 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-10 23:10 [gentoo-dev] libpcre.so.3 - Compatibility with Debian James Le Cuirot 2016-08-11 5:53 ` Kent Fredric 2016-08-11 9:43 ` Ulrich Mueller @ 2016-08-11 16:23 ` james 2016-08-11 16:32 ` Mart Raudsepp 2 siblings, 1 reply; 38+ messages in thread From: james @ 2016-08-11 16:23 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 16:23 ` james @ 2016-08-11 16:32 ` Mart Raudsepp 2026-08-13 18:27 ` james 0 siblings, 1 reply; 38+ messages in thread From: Mart Raudsepp @ 2016-08-11 16:32 UTC (permalink / raw To: gentoo-dev Ü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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 16:32 ` Mart Raudsepp @ 2026-08-13 18:27 ` james 2016-08-11 18:02 ` Matt Turner 0 siblings, 1 reply; 38+ messages in thread From: james @ 2026-08-13 18:27 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2026-08-13 18:27 ` james @ 2016-08-11 18:02 ` Matt Turner 2016-08-11 18:27 ` Deven Lahoti 0 siblings, 1 reply; 38+ messages in thread From: Matt Turner @ 2016-08-11 18:02 UTC (permalink / raw To: gentoo development 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian 2016-08-11 18:02 ` Matt Turner @ 2016-08-11 18:27 ` Deven Lahoti 0 siblings, 0 replies; 38+ messages in thread From: Deven Lahoti @ 2016-08-11 18:27 UTC (permalink / raw To: gentoo-dev [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2016-08-18 6:06 UTC | newest] Thread overview: 38+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-10 23:10 [gentoo-dev] libpcre.so.3 - Compatibility with Debian James Le Cuirot 2016-08-11 5:53 ` Kent Fredric 2016-08-11 15:41 ` Mike Gilbert 2016-08-11 18:57 ` Patrick McLean 2016-08-18 5:45 ` Daniel Campbell 2016-08-11 9:43 ` Ulrich Mueller 2016-08-11 10:11 ` James Le Cuirot 2016-08-11 10:56 ` Ulrich Mueller 2016-08-11 11:20 ` James Le Cuirot 2016-08-11 11:49 ` Kristian Fiskerstrand 2016-08-11 12:04 ` Ulrich Mueller 2016-08-11 12:13 ` Rich Freeman 2016-08-11 14:57 ` Mart Raudsepp 2016-08-11 15:03 ` Ciaran McCreesh 2016-08-11 15:05 ` Ian Stakenvicius 2016-08-11 15:15 ` Mart Raudsepp 2016-08-11 19:56 ` James Le Cuirot 2016-08-11 20:07 ` Ian Stakenvicius 2016-08-11 21:34 ` Kent Fredric 2016-08-11 22:00 ` Mike Gilbert 2016-08-12 1:19 ` Mart Raudsepp 2016-08-18 6:06 ` Daniel Campbell 2016-08-11 20:50 ` Michał Górny 2016-08-11 21:30 ` James Le Cuirot 2016-08-11 21:55 ` Mike Gilbert 2016-08-12 0:27 ` Patrick McLean 2016-08-12 0:32 ` Kent Fredric 2016-08-12 14:12 ` james 2016-08-12 15:39 ` Kent Fredric 2016-08-12 17:40 ` james 2016-08-12 17:48 ` M. J. Everitt 2016-08-12 22:36 ` Rich Freeman 2016-08-12 17:55 ` Kent Fredric 2016-08-11 16:23 ` james 2016-08-11 16:32 ` Mart Raudsepp 2026-08-13 18:27 ` james 2016-08-11 18:02 ` Matt Turner 2016-08-11 18:27 ` Deven Lahoti
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox