Re: less aggressive glibc rebuilds
On 9/6/18 1:42 PM, glen wrote: So it is just upgrading the package you want and glibc, not a big issue. services need to be restarted, especially ones using locale data. and that means services need to be restarted, and it's a big issue here. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: less aggressive glibc rebuilds
On 9/6/18 11:59 AM, Jacek Konieczny wrote: openssl upgrades are much more problematic. openssl we have artificial dependency in pld because openssl library tended to change symbols(?), and those were not versioned. probably git blame to find detailed answer. for example sslv3 drop would not be compatible, but it was enabled shortly back. but that ssl deps i think we can drop those "strict deps" in th. openssl releases are pretty stable upstream nowadays. ps: in pld-ac i've removed such hard deps that are present in openssl<>openssh in pld-th -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: less aggressive glibc rebuilds
On 9/6/18 11:59 AM, Jacek Konieczny wrote: On 2018-09-06 10:50, glen wrote: could we make not so often glibc upgrades in th? at least keep builders glibc version low, so that built packages do not require the latest and bleeding glibc SONAME symbols? (unless there's actual benefit in that package for newer glibc) it's very disturbing that wanting to install some new package, i'm forced to upgrade whole system. Why whole system? Glibc upgrades are backward compatible most of the time. So it is just upgrading the package you want and glibc, not a big issue. I cannot recall the last time glibc upgrade pulled anything more. openssl upgrades are much more problematic. i mean if i build thing with glibc 2.28 installed, and my system has 2.27, then glibc upgrade is needed as well due versioned glibc symbols Processing dependencies... open-vm-tools-10.1.5-2.x86_64 obsoleted by open-vm-tools-10.3.0-2.x86_64 open-vm-tools-10.3.0-2.x86_64 marks glibc-2.28-3.x86_64 (cap libc.so.6(GLIBC_2.28)(64bit)) glibc-2.27-8.x86_64 obsoleted by glibc-2.28-3.x86_64 greedy upgrade iconv-2.27-8.x86_64 to 2.28-3.x86_64 (unresolved glibc = 6:2.27-8) iconv-2.27-8.x86_64 obsoleted by iconv-2.28-3.x86_64 greedy upgrade glibc-localedb-delfi-2.27.0-1.x86_64 to 2.28.1-1.x86_64 (unresolved iconv = 6:2.27) glibc-localedb-delfi-2.27.0-1.x86_64 obsoleted by glibc-localedb-delfi-2.28.1-1.x86_64 greedy upgrade glibc-libcrypt-2.27-8.x86_64 to 2.28-3.x86_64 (unresolved glibc = 6:2.27-8) glibc-libcrypt-2.27-8.x86_64 obsoleted by glibc-libcrypt-2.28-3.x86_64 greedy upgrade glibc-misc-2.27-8.x86_64 to 2.28-3.x86_64 (unresolved glibc = 6:2.27-8) glibc-misc-2.27-8.x86_64 obsoleted by glibc-misc-2.28-3.x86_64 glibc-2.28-3.x86_64 marks ldconfig-2.28-3.x86_64 (cap ldconfig = 6:2.28-3) ldconfig-2.27-8.x86_64 obsoleted by ldconfig-2.28-3.x86_64 open-vm-tools-10.3.0-2.x86_64 marks xmlsec1-1.2.26-2.x86_64 (cap libxmlsec1.so.1()(64bit)) xmlsec1-1.2.26-2.x86_64 marks libxslt-1.1.32-1.x86_64 (cap libxslt >= 1.0.20) There are 9 packages to install (8 marked by dependencies), 7 to remove: I open-vm-tools-10.3.0-2.x86_64 D glibc-2.28-3.x86_64 glibc-libcrypt-2.28-3.x86_64 glibc-localedb-delfi-2.28.1-1.x86_64 glibc-misc-2.28-3.x86_64 iconv-2.28-3.x86_64 ldconfig-2.28-3.x86_64 libxslt-1.1.32-1.x86_64 D xmlsec1-1.2.26-2.x86_64 R glibc-2.27-8.x86_64 glibc-libcrypt-2.27-8.x86_64 glibc-localedb-delfi-2.27.0-1.x86_64 glibc-misc-2.27-8.x86_64 iconv-2.27-8.x86_64 ldconfig-2.27-8.x86_64 open-vm-tools-10.1.5-2.x86_64 This operation will use 7.0MB of disk space. if open-vm-tools was built with older glibc present on builder, i could just install the package, not pull glibc and related deps and this can recurse big enough if some upgraded dependent package pulls another library rebuild, etc. on some other system i was forced to install 900mb packages due gdbm, ffmpeg, etc libraries which all stareted from simple GLIBC_2.28 dep. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: less aggressive glibc rebuilds
On 2018-09-06 10:50, glen wrote: > could we make not so often glibc upgrades in th? > > at least keep builders glibc version low, so that built packages do not > require the latest and bleeding glibc SONAME symbols? (unless there's > actual benefit in that package for newer glibc) > > it's very disturbing that wanting to install some new package, i'm > forced to upgrade whole system. Why whole system? Glibc upgrades are backward compatible most of the time. So it is just upgrading the package you want and glibc, not a big issue. I cannot recall the last time glibc upgrade pulled anything more. openssl upgrades are much more problematic. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: less aggressive glibc rebuilds
On 9/6/18 11:56 AM, Arkadiusz Miśkiewicz wrote: On 06/09/2018 10:50, glen wrote: could we make not so often glibc upgrades in th? glibc is released every ~6 months and that's not "often" that's your opinion. and what is often or not to one's system was not the question in the original post. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: less aggressive glibc rebuilds
On 06/09/2018 10:50, glen wrote: could we make not so often glibc upgrades in th? glibc is released every ~6 months and that's not "often" -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
less aggressive glibc rebuilds
could we make not so often glibc upgrades in th? at least keep builders glibc version low, so that built packages do not require the latest and bleeding glibc SONAME symbols? (unless there's actual benefit in that package for newer glibc) it's very disturbing that wanting to install some new package, i'm forced to upgrade whole system. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
