Re: RPM packaging and ldconfig handling

2018-01-31 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-31 at 14:53 +0100, Kamil Dudka wrote:
> On Wednesday, January 31, 2018 2:00:08 PM CET Florian Weimer wrote:
> > On 01/31/2018 01:54 PM, Kamil Dudka wrote:
> > 
> > > See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.
> > > 
> > > What is the recommended way to make libcurl{-minimal} build properly
> > > again?
> > 
> > I think in this situation, you need to disable this feature using:
> > 
> > %undefine __brp_ldconfig
> 
> Thank both of you for the suggestion!  It has indeed resolved the problem.
> 
> > Depending on whether you can include the appropriate symbolic links in 
> > the packages themselves,
> 
> Those symlinks are created by libtool, so I believe they are appropriate.
> 
> > you can or cannot remove the explicit ldconfig calls.
> 
> %undefine __brp_ldconfig removes the build-time ldconfig calls as I
> understand 
> it.  Are you saying that I can remove the following install-time ldconfig 
> calls, too?

If you don't simply merge master branch to others, then yes. Otherwise, you
should consider using macro we've created.

> %post -n libcurl -p /sbin/ldconfig
> 
> %postun -n libcurl -p /sbin/ldconfig
> 
> %post -n libcurl-minimal -p /sbin/ldconfig
> 
> %postun -n libcurl-minimal -p /sbin/ldconfig

%ldconfig_scriptlets -n libcurl
%ldconfig_scriptlets -n libcurl-minimal
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxyuQACgkQaVcUvRu8
X0yNURAAvoM8dUhwc4godVoc7O5y7t41JUijeDkhBLzSQSouUwAIefeaNWqO2Wr4
fy4TBY7A4piyKlwXdGsmjh7GGpwl3l623zoaqaugL/8hs8212JVelFQs7WhE6d2r
s6sMsy5Y9spue8FpT+rQ8Tn+Qaqyeo9ZCHfo5xUrvSj/YeEyWTssZa7XWjPNHb5h
Loy4n8kivD2tq+ycAIx+3w6+U1DsyRvhYUmQy/DwfegLy5TSuybf2ott42mZLy5k
WkEHZZ/gJnIMuW0Ra+E2unN7zpeKnC6Eg+ss0mhBb33C0WXLtZvWCHLxTrliheuy
Bn5+aGpf01zCev2r9/iK91/MR1ZtCxPMK7/P68qEQ4RoCrGUT3GtBBuSQ9MzFqge
If8lFHVYSfNKpdzSBLTlwB+2ONcStylA1jUg9MiSRN6anH5867pJvTF+4iGOWfn6
E2yf4IA57p//xGH5LIoXKMMCYWt5bcVnydxnznEHwGYBKAQgk9/4eBhkGSHZBJAQ
qAUC/V9SXuvFNW8c77sJKBlPXirFRIdBa/whHzyGKwBDAqCCW6h0r2yFQ84pmVYF
5xFZpkWdMOBbAa1Rz2NqojfoJqz8b4YGkPtYGve3TZ/nqoDr/wxpiKsobV4oOK63
aAgQh+bk1UD+9HqLOcxuPFRYnxWeTb9Vo0QBjk8IN7Fkt2A6goQ=
=1OCS
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Kamil Dudka 
On Wednesday, January 31, 2018 2:00:08 PM CET Florian Weimer wrote:
> On 01/31/2018 01:54 PM, Kamil Dudka wrote:
> 
> > See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.
> > 
> > What is the recommended way to make libcurl{-minimal} build properly
> > again?
> 
> I think in this situation, you need to disable this feature using:
> 
> %undefine __brp_ldconfig

Thank both of you for the suggestion!  It has indeed resolved the problem.

> Depending on whether you can include the appropriate symbolic links in 
> the packages themselves,

Those symlinks are created by libtool, so I believe they are appropriate.

> you can or cannot remove the explicit ldconfig calls.

%undefine __brp_ldconfig removes the build-time ldconfig calls as I understand 
it.  Are you saying that I can remove the following install-time ldconfig 
calls, too?

%post -n libcurl -p /sbin/ldconfig

%postun -n libcurl -p /sbin/ldconfig

%post -n libcurl-minimal -p /sbin/ldconfig

%postun -n libcurl-minimal -p /sbin/ldconfig

> I don't think it's feasible or even desirable to teach ldconfig about 
> the RemovePathPostfixes RPM feature.
> 
> Thanks,
> Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Richard Shaw 
On Wed, Jan 31, 2018 at 7:38 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> > 2. Is the plan to update for all supported Fedora releases and not just
> > Rawhide? Otherwise we're back in conditional hell which I thought we were
> > trying to move away from. (Again, the suggested workflow in the wiki for
> > managing branches is to merge across them).
>
> If you use macro, then you should not care at all, it will evaluate to
> ldconfig
> calls on old releases and to noop on F28+. This is mentioned on Change
> Page.


Thanks for clearing that up for me!

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Neal Gompa 
On Wed, Jan 31, 2018 at 8:14 AM, Richard Shaw  wrote:
> I re-skimmed the whole thread so I apologize if I missed it, but I have a
> couple of questions:
>
> 1. The packaging guidelines still require the explicit use of calling
> ldconfig, so even if it's not technically required, it would be against the
> guidelines to remove them, correct?
>

New guidelines are being drafted:
https://pagure.io/packaging-committee/issue/654

> 2. Is the plan to update for all supported Fedora releases and not just
> Rawhide? Otherwise we're back in conditional hell which I thought we were
> trying to move away from. (Again, the suggested workflow in the wiki for
> managing branches is to merge across them).
>

We could technically push them to all supported Fedora releases, but
that would force a requirement to have a specific minimum version of
glibc per distribution release, and that's just too much. It's easier
to just let it fade out of existence.

In addition, the usage of ldconfig macros being made should make this
a non-issue.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-31 at 07:14 -0600, Richard Shaw wrote:
> I re-skimmed the whole thread so I apologize if I missed it, but I have a
> couple of questions:
> 
> 1. The packaging guidelines still require the explicit use of calling
> ldconfig, so even if it's not technically required, it would be against the
> guidelines to remove them, correct?

tibbs is working on updating guidelines[0].

> 2. Is the plan to update for all supported Fedora releases and not just
> Rawhide? Otherwise we're back in conditional hell which I thought we were
> trying to move away from. (Again, the suggested workflow in the wiki for
> managing branches is to merge across them).

If you use macro, then you should not care at all, it will evaluate to ldconfig
calls on old releases and to noop on F28+. This is mentioned on Change Page.

[0] https://pagure.io/packaging-committee/issue/654
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxxukACgkQaVcUvRu8
X0xmuw/8CczKI4GTPB++G4Nep1g3vw2CW9X6Nc2TaukNsGD6QAIIgxbmV5xwVpbX
c1IzAsjl2Zln9ft51hwrnxfOqh69lGOUWFeNmzCaRjU1UoHZ6yx96FNuytuJttcb
Jd9eqsXtfus2LS8oaePulg1k4lbdVHowrvR03U3rRKY6Z6udtcwIihJXaxJ6LIVA
X5Wn1wp3v99Xkk5kRwaYM9Xx38x9kX/wayAdeVW8DD6CtYJorhpMYajGXXzuCwR4
ic1S/EXQnQg+lSZjbhzvdtwsDVgYAdNs0KoOWcrC7RbeG8kSz81iG4jMVZYeVImH
vqbsy3mE6i7noG7Bo4vFX0JZ5yMPXp+pON2ifvU1ZXlDdxfxpqlOL27AFz9HKrzM
jiCvHHBg4fOrLMX/rR1cSqV95jxg0Dfpcih9OKkV+SRKORebCYocpb0ljzuT34pu
Ay1FTFtHhCpFT3e/rgv3hgS0YygWW7iHMTz8QCNM8cN6JfO5EoVc0PJQY5wZtH+f
EbFtTUTd8r81QxEB9TKoVcevsiEXhf65WEbmD5sSqWBfVsi6MY7lALZGU32EbKx4
WdOYVHIxQK8AO0mMnimM3V1osLEhZFERASy137YncKNL5OXbsuS8tzAiShqANwVv
sejFhUqBOo+DGeycRgQrRoziLClZpQlUISRIkkMDFbL1W5PgGwU=
=FiJi
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Richard Shaw 
I re-skimmed the whole thread so I apologize if I missed it, but I have a
couple of questions:

1. The packaging guidelines still require the explicit use of calling
ldconfig, so even if it's not technically required, it would be against the
guidelines to remove them, correct?

2. Is the plan to update for all supported Fedora releases and not just
Rawhide? Otherwise we're back in conditional hell which I thought we were
trying to move away from. (Again, the suggested workflow in the wiki for
managing branches is to merge across them).

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-31 at 14:00 +0100, Florian Weimer wrote:
> On 01/31/2018 01:54 PM, Kamil Dudka wrote:
> > See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.
> > 
> > What is the recommended way to make libcurl{-minimal} build properly again?
> 
> I think in this situation, you need to disable this feature using:
> 
> %undefine __brp_ldconfig
> 
> Depending on whether you can include the appropriate symbolic links in 
> the packages themselves, you can or cannot remove the explicit ldconfig 
> calls.
> 
> I don't think it's feasible or even desirable to teach ldconfig about 
> the RemovePathPostfixes RPM feature.

Well, we could expose `removePostfixes` as environment variable when brps are
executed, so we could do some workarounds like processing all those libraries
separately followed by renaming soname back.

Shouldn't be hard to do.. I will try to prepare patch later this week.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxv1IACgkQaVcUvRu8
X0z7xw/9F44a2CewhQEMC1u52IVXMl4KvI2dvn9uNTWRA2f0PR1VZ4gLxaycrKKC
mx7p87FaFYpYFqIm2p0iITcjA1gu3ejVfCzHI+I3Bb0I90VlM0rV7U2s2E8TvoNO
i4Wr1c+gMn5boVAqPeO6D1Wk8jWz4ka0zsdsJ7PbhBt/2N3ITMs0Byxg072HYy7V
Ly8ztJyHONIYFCYi9exqWZcgeTihuNsMro8TFjQ60RApCaSeY/cEIRN+C8yuiee8
Q8BQWyE4b0nBHgLwLFAx+UHbO9Rt85wZGRsKOtJhtAAdOWq0w90GZedYgPuq0Y95
YAUCm8uSeBr328eRKOI6usdAJOwqz/B/hA7cSu12xD8leo7MAQjJhhfHaKTJIXAc
/5gCHUVGSuZjjB/+Alg6Fwe5ggQCtQz5rKHPtHyRL8JjDo/DecK8jtEcVAaSaJiJ
BMWlF1ZmMZS8GBJEinV/atyxGUIxv/huO3np8G6ThnwfcK+giIiAvFStkyap5mbv
yjrnKU+hOOnFTdiKrbuhIDqRIIjcxDUlEdz9vV5LNR0DOqW7hMR2CTV/CWmLZEck
XMCCPGmBsdmFKQ2smdIF6dMz+xG36E8IjbdKKd7LhBtGcL104PLLA4H3HkB9/ItJ
rvcA4ySTvF1YfNP0HuVMcTeJYzrxkG9YvPDymK/sjqQVKt1BIc0=
=em37
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-01-31 at 13:54 +0100, Kamil Dudka wrote:
> On Tuesday, January 30, 2018 9:57:39 AM CET Igor Gnatenko wrote:
> > brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"` and
> > there
> > is no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory we
> > could supply one (empty), but I would ask Florian what would be the best to
> > do. --
> > -Igor Gnatenko
> 
> This change broke the build of libcurl{-minimal} because ldconfig now
> operates
> on an intermediate layout of the installed shared libraries, which is needed
> by the RemovePathPostfixes feature of RPM, instead of the final layout that
> is
> actually packaged as libcurl and libcurl-minimal.
> 
> 
> At the end of %install, the build root contains this:
> 
> + ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
> total 8324
> lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so ->
> libcurl.so.4.5.0
> lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so.4 ->
> libcurl.so.4.5.0
> -rwxr-xr-x. 1 mockbuild mockbuild 4398816 Jan 31 12:46 libcurl.so.4.5.0
> -rwxr-xr-x. 1 mockbuild mockbuild 4120952 Jan 31 12:46
> libcurl.so.4.5.0.minimal
> lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so.4.minimal
> -> libcurl.so.4.5.0
> drwxr-xr-x. 2 mockbuild mockbuild  24 Jan 31 12:46 pkgconfig
> 
> 
> But at the beginning of %check, the build root contains this:
> 
> + ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
> total 1172
> lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so ->
> libcurl.so.4.5.0
> lrwxrwxrwx. 1 mockbuild mockbuild 24 Jan 31 12:46 libcurl.so.4 ->
> libcurl.so.4.5.0.minimal
> -rwxr-xr-x. 1 mockbuild mockbuild 614896 Jan 31 12:46 libcurl.so.4.5.0
> -rwxr-xr-x. 1 mockbuild mockbuild 577760 Jan 31 12:46
> libcurl.so.4.5.0.minimal
> lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so.4.minimal ->
> libcurl.so.4.5.0
> drwxr-xr-x. 2 mockbuild mockbuild 24 Jan 31 12:46 pkgconfig
> 
> 
> See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.
> 
> What is the recommended way to make libcurl{-minimal} build properly again?

Just `%undefine __brp_ldconfig`. And you can safely remove / replace with macro
calls to ldconfig because you are packaging DSO symlinks and it will continue
working fine..

I will think how we can make support for RemovePathPostfixes.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxvrgACgkQaVcUvRu8
X0z61A//an3YDqsC86tA1VCWMgx7gDSutV3eXS1SkvYWGu+h9MlZRTQmoa9alpDd
FFZrYnxt77ln71IvOF+IAhL1MxbwFmkPAU8n9+q6o3jVH1wN8F5iRNzqjyX91StA
Ib/YK781/Bjk4SflsULmqb5sCANeTr1Qb0W4JEd9mE0iGSVZTJ03DC5jheZKw3Lf
UcPaI3jPHv7wztZ6TRzf0abr2e6o77gkYggkC9qq2bZ/XnTUbCsV/82seiF0wwK2
+x1tQLeDFQf+SMJo5WnB4wX1oh/sQBYPEzsbzFaMCCRHY5R21xmYqtM8lXVC2EzW
S2cZ36IsxqljbFR7U3W5TNPZdROTiDEE24Bh1ztZaDx/CG9x65hyb6tbJCuzikPw
HajJjmODcKfsXXESoXGFJ4FQknMkXyCWa8M1HKhTFnR8oeNymbSn2dMEudBWiIQv
SU3NhYjxOkLvPKnXt7JAgXDysNwflEjje8QfvAUFpxAvOAMtBDoNnPfp2si67sMS
sI+iQaF/CBFLYQRqQdFCiPASMUk6H7myeh2/3w/0yjG4tC6gpU7kWa5bvLReZUNU
lVCnhMETnGLbmwMKmZzfg4ARZTeN9BX5vtnMpaxb6Yc3ypfPu4B0YPNA12U1+xKp
CbJsfB09lVOBVGvJVxG8TC6AwgYRAWwLkHoJT57cygOL1Kfvtv0=
=fbEP
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Florian Weimer 

On 01/31/2018 01:54 PM, Kamil Dudka wrote:

See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.

What is the recommended way to make libcurl{-minimal} build properly again?


I think in this situation, you need to disable this feature using:

%undefine __brp_ldconfig

Depending on whether you can include the appropriate symbolic links in 
the packages themselves, you can or cannot remove the explicit ldconfig 
calls.


I don't think it's feasible or even desirable to teach ldconfig about 
the RemovePathPostfixes RPM feature.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-31 Thread Kamil Dudka 
On Tuesday, January 30, 2018 9:57:39 AM CET Igor Gnatenko wrote:
> brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"` and there
> is no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory we
> could supply one (empty), but I would ask Florian what would be the best to
> do. --
> -Igor Gnatenko

This change broke the build of libcurl{-minimal} because ldconfig now operates
on an intermediate layout of the installed shared libraries, which is needed
by the RemovePathPostfixes feature of RPM, instead of the final layout that is
actually packaged as libcurl and libcurl-minimal.


At the end of %install, the build root contains this:

+ ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
total 8324
lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so -> 
libcurl.so.4.5.0
lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so.4 -> 
libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 4398816 Jan 31 12:46 libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 4120952 Jan 31 12:46 libcurl.so.4.5.0.minimal
lrwxrwxrwx. 1 mockbuild mockbuild  16 Jan 31 12:46 libcurl.so.4.minimal -> 
libcurl.so.4.5.0
drwxr-xr-x. 2 mockbuild mockbuild  24 Jan 31 12:46 pkgconfig


But at the beginning of %check, the build root contains this:

+ ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
total 1172
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so -> 
libcurl.so.4.5.0
lrwxrwxrwx. 1 mockbuild mockbuild 24 Jan 31 12:46 libcurl.so.4 -> 
libcurl.so.4.5.0.minimal
-rwxr-xr-x. 1 mockbuild mockbuild 614896 Jan 31 12:46 libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 577760 Jan 31 12:46 libcurl.so.4.5.0.minimal
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so.4.minimal -> 
libcurl.so.4.5.0
drwxr-xr-x. 2 mockbuild mockbuild 24 Jan 31 12:46 pkgconfig


See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.

What is the recommended way to make libcurl{-minimal} build properly again?

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Tomasz Kłoczko 
On 30 January 2018 at 17:21, Tim Landscheidt  wrote:
[..]

> You can help move this forward by publishing the script(s)
> you used (or the patches that still apply cleanly if you
> wrote them manually).
>

There is no any this kind script because ALL Fedora specs unstructured
formatting/indentations makes writing such scripts IMPOSSIBLE!!!
Because of this MOST of the changes per each package needs to be done
MANUALLY.
Is that CLEAR NOW?
How many times I must repeat this to punch kind of "mental helmet" people
like you?

Whole idea of the series mass changes was about aligning all specs to the
form when after many such iterations it will be possible to do more and
more other changes using simple sed regexps. NOW it is NOT POSSIBLE. Is
that clear now?

It is classic chicken and egg problem, and by proposing series of mass
cleanups I'm trying to cut this IMPOSSIBILITY loop.

Try to think why Igor already have done all changes in few batches just
going across all specs ALPHABETICALLY?
Answer: because each spec needs to be checked and modified MANUALLY!!!

And just for the record: again you did not answered on my questions
ignoring "en block" arguments and questions turning this thread again into
"ad hominem" conversation.
Again: my humble person has nothing to do with subject called "Fedora
methodology".

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Tim Landscheidt 
Tomasz Kłoczko  wrote:

> […]

> Who said that I'm demanding something?
> Look one more time on https://pagure.io/packaging-committee/issue/736
> Igor took this tasks VOLUNTARILY and started working on necessary specs 
> before I've delivered batch of patches.
> When I found that number of already done modifications is trashing already 
> many patches which I had prepared it was no sense to be (as me) involved in 
> helping finish
> this.
> Now still is not finished about 20%.
> Just please answer on the questions:
> - Who will finish this?
> - Why it is done so badly?
> - What is the sense submitting more such mass changes if it is good chance 
> that they'll be not finished as well? (and now you are telling me that I'm 
> this bad guy because
> I've been showing those "naked pictures" to other people)

You can help move this forward by publishing the script(s)
you used (or the patches that still apply cleanly if you
wrote them manually).

Also, just to state the obvious for most: This is some tidy-
ing up.  It's good if it's done, but it is not blocking any-
thing.  If someone already has patched "only" 20 % of the
specs, that is good, not bad, because the work to be done
has decreased by a fifth.

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Tomasz Kłoczko 
On 30 January 2018 at 12:32, Matthew Miller 
wrote:

> On Tue, Jan 30, 2018 at 03:07:22AM +, Tomasz Kłoczko wrote:
> > OK. So if I'll be nice, explicit and concise it will cause that Igor will
> > finish at least one mass change before start another one?
> > Igor could you pleas confirm above?
>
> Seriously, quit it. Igor doesn't work for you. Igor doesn't work for
> me. Yet, he's actively working to make Fedora better and to improve our
> packaging. That's awesome. An appropriate response might be: "Awesome!
> Thanks for kicking off this effort. I see there's work to be done yet.
> How can I help?"
>
> Demanding that other people do things isn't the way we do things.
>

Who said that I'm demanding something?
Look one more time on https://pagure.io/packaging-committee/issue/736
Igor took this tasks VOLUNTARILY and started working on necessary specs
before I've delivered batch of patches.
When I found that number of already done modifications is trashing already
many patches which I had prepared it was no sense to be (as me) involved in
helping finish this.
Now still is not finished about 20%.
Just please answer on the questions:
- Who will finish this?
- Why it is done so badly?
- What is the sense submitting more such mass changes if it is good chance
that they'll be not finished as well? (and now you are telling me that I'm
this bad guy because I've been showing those "naked pictures" to other
people)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Matthew Miller 
On Tue, Jan 30, 2018 at 03:07:22AM +, Tomasz Kłoczko wrote:
> OK. So if I'll be nice, explicit and concise it will cause that Igor will
> finish at least one mass change before start another one?
> Igor could you pleas confirm above?

Seriously, quit it. Igor doesn't work for you. Igor doesn't work for
me. Yet, he's actively working to make Fedora better and to improve our
packaging. That's awesome. An appropriate response might be: "Awesome!
Thanks for kicking off this effort. I see there's work to be done yet.
How can I help?"

Demanding that other people do things isn't the way we do things.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Tom Hughes 

On 30/01/18 12:06, Florian Weimer wrote:

On 01/30/2018 01:01 PM, Vít Ondruch wrote:



Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):

On 01/30/2018 09:57 AM, Igor Gnatenko wrote:

brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"`
and there is
no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory
we could
supply one (empty), but I would ask Florian what would be the best to
do.


But why does it print /etc/ld.so.conf, and not the path in the
buildroot?  That concerns me.


I would be concerned even if it issued warning about /etc/ld.so.conf in
buildroot ...


Sure, it would be nice to avoid the warning, and I will work on 
something for glibc in rawhide to support this.  But I would also like 
to understand if ldconfig is actually using the wrong path.


So you're expecting to see $RPM_BUILD_ROOT/etc/ld.so.conf as the 
reported path right?


That doesn't seem to be how the -r option to ldconfig works though
because it chroots so as far as it's concerned the relative path is
the path it is accessing:

% sudo strace ldconfig -N -r /tmp
...
chroot("/tmp")  = 0
chdir("/")  = 0
openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = -1 ENOENT (No such file 
or directory)

...
ldconfig: Warning: ignoring configuration file that cannot be opened: 
/etc/ld.so.conf: No such file or directory


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Florian Weimer 

On 01/30/2018 01:01 PM, Vít Ondruch wrote:



Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):

On 01/30/2018 09:57 AM, Igor Gnatenko wrote:

brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"`
and there is
no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory
we could
supply one (empty), but I would ask Florian what would be the best to
do.


But why does it print /etc/ld.so.conf, and not the path in the
buildroot?  That concerns me.


I would be concerned even if it issued warning about /etc/ld.so.conf in
buildroot ...


Sure, it would be nice to avoid the warning, and I will work on 
something for glibc in rawhide to support this.  But I would also like 
to understand if ldconfig is actually using the wrong path.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Vít Ondruch 


Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):
> On 01/30/2018 09:57 AM, Igor Gnatenko wrote:
>> brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"`
>> and there is
>> no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory
>> we could
>> supply one (empty), but I would ask Florian what would be the best to
>> do.
>
> But why does it print /etc/ld.so.conf, and not the path in the
> buildroot?  That concerns me.

I would be concerned even if it issued warning about /etc/ld.so.conf in
buildroot ...


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Florian Weimer 

On 01/30/2018 09:57 AM, Igor Gnatenko wrote:

brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"` and there is
no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory we could
supply one (empty), but I would ask Florian what would be the best to do.


But why does it print /etc/ld.so.conf, and not the path in the 
buildroot?  That concerns me.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-01-30 at 09:02 +0100, Vít Ondruch wrote:
> ~~~
> 
> + /usr/lib/rpm/redhat/brp-ldconfig
> /sbin/ldconfig: Warning: ignoring configuration file that cannot be
> opened: /etc/ld.so.conf: No such file or directory
> 
> ~~~
> 
> 
> What is this ^^? Should I be worried about it?

brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"` and there is
no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory we could
supply one (empty), but I would ask Florian what would be the best to do.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpwM4MACgkQaVcUvRu8
X0wmKg/9EpqqwJ+uG3dVB4NhktxUS/MFZdh1eAw31YyxYTZROg61UnwGFfwi3yDB
mjpoTvckrgQnsYqa9NkUqrZ4/b7hKgEHJn5Gv6k//sGEHL85mStHfTz/9Ada/Xf1
mIdKI6OnIiYZCUeBzN3bA7YQbb9a1xeFj+Jd7A/rwmDAXfYNKtAWhyXwGCGDYflQ
68xcL1yE9EKRvJ5gYPl1/JeipwNcBe9ztmLooDhCVXb/4eRNaC7NP84QRDgh23hB
EDC8KhP2kQWHpKHEWI3irqwFK4i+WjtgDVMi4u/wSdtw9dAhm/jiEgI8nqQS+o3A
j02hCDxgbTx6uhxFDM5RaEbm9H4QMy7FwwOFc4I8YVqIsorRk/va50rQYqYY9iu/
EzSn2UK6xkltwBs2xi/6IRNfCvt+wHcOK4c8u20Nr/yxBl+n0AvbrFntPiIyoaKD
9PWySte92oa2kP8JSdh4xZlE+IpZkW6oPLh2rwaRMriAuZNFKeUSQceQCUjO8mFe
QVzjFjuwhOv7V7xMXZiSiEVt1LAren5Nt88WxWOyG4LRqJz87+oDfkzFijmtFgWD
YxTybfvgQRM3ZkUb02SbvKyFD82kCeXnf2Dr387Dr3AKQyIlqfpdFvCRwyb4Vc72
djsZkGgaUK87i4qLxbQRUpgM56U+ZZKV9+SBfRc1ipHwcRh/JXs=
=DCoF
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Vít Ondruch 


Dne 30.1.2018 v 09:15 Florian Weimer napsal(a):
> On 01/30/2018 09:02 AM, Vít Ondruch wrote:
>> ~~~
>>
>> + /usr/lib/rpm/redhat/brp-ldconfig
>> /sbin/ldconfig: Warning: ignoring configuration file that cannot be
>> opened: /etc/ld.so.conf: No such file or directory
>>
>> ~~~
>>
>>
>> What is this ^^? Should I be worried about it?
>
> Context?  ldconfig definitely shouldn't print /etc/ld.so.conf.
>
> Thanks,
> Florian

Local build of Ruby:


~~~
diff --git a/ruby.spec b/ruby.spec
index 6eff5d9..e7b5114 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -21,7 +21,7 @@
 %endif
 
 
-%global release 87
+%global release 88
 %{!?release_string:%global release_string
%{?development_release:0.}%{release}%{?development_release:.%{development_release}}%{?dist}}
 
 # The RubyGems library has to stay out of Ruby directory three, since the
@@ -742,10 +742,6 @@ sed -i '/def test_mdns_each_address$/,/^  end$/
s/^/#/' test/resolv/test_mdns.rb
 
 make check TESTS="-v $DISABLE_TESTS"
 
-%post libs -p /sbin/ldconfig
-
-%postun libs -p /sbin/ldconfig
-
 %files
 %license BSDL
 %license COPYING
@@ -1062,6 +1058,9 @@ make check TESTS="-v $DISABLE_TESTS"
 %{gem_dir}/specifications/xmlrpc-%{xmlrpc_version}.gemspec
 
 %changelog
+* Tue Jan 30 2018 Vít Ondruch  - 2.5.0-88
+- Drop obsolete ldconfig scriptlets.
+
 * Tue Jan 09 2018 Vít Ondruch  - 2.5.0-87
 - Fix segfaults during generating of documentation.
 
~~~


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Florian Weimer 

On 01/30/2018 09:02 AM, Vít Ondruch wrote:

~~~

+ /usr/lib/rpm/redhat/brp-ldconfig
/sbin/ldconfig: Warning: ignoring configuration file that cannot be
opened: /etc/ld.so.conf: No such file or directory

~~~


What is this ^^? Should I be worried about it?


Context?  ldconfig definitely shouldn't print /etc/ld.so.conf.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-30 Thread Vít Ondruch 
~~~

+ /usr/lib/rpm/redhat/brp-ldconfig
/sbin/ldconfig: Warning: ignoring configuration file that cannot be
opened: /etc/ld.so.conf: No such file or directory

~~~


What is this ^^? Should I be worried about it?


V.


Dne 29.1.2018 v 18:18 Florian Weimer napsal(a):
> Igor committed a change to glibc so that from Fedora 28 going forward,
> glibc will run ldconfig after the transaction if any of the library
> directory trees was modified.
>
> This means that libraries which package the lib*.so.* symbolic links
> will no longer have to run ldconfig in %postin/%postun, and we can
> automate the creation of those symbolic links with a buildroot policy
> hook, see:
>
>   
>
> Packages which edit ld.so search paths will still have to run ldconfig
> in %postin/%postun, as before.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Tomasz Kłoczko 
On 30 January 2018 at 02:11, Tim Landscheidt  wrote:
[..]

> Unfortunately, progress in Fedora and similar projects is
> not made by telling people what they are doing wrong, but by
> doing The Right Thing™ yourself or in collaboration with
> others.  And even if one is reporting a fault, there are
> ways to enable someone to fix that fault and there ways to
> overwhelm them with superfluous information that makes their
> work harder.


> For example, take the first line of your text I quoted
> above.  I can tell you that you used "with" there twice, or
> I can hide that nugget in a long diatribe about the English
> language, HTML mail and whatever.  If your time is limited,
> you will probably prefer one over the other.
>
> Or, to paraphrase perlstyle(1): Be explicit.  Be concise.  Be
> nice.
>

OK. So if I'll be nice, explicit and concise it will cause that Igor will
finish at least one mass change before start another one?
Igor could you pleas confirm above?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Tim Landscheidt 
Tomasz Kłoczko  wrote:

> […]

> This is like with with problems on taking care of the production issues or 
> faults.
> Always needs to be someone who is controlling whole situation but this person 
> does not need to to person doing all OS, HW, app, db related things which 
> needs to be
> changed.
> At the end such person in bigger organisation sometimes is taking 
> responsibility to teach other technical personnel about how to prevent 
> similar faults.

Unfortunately, progress in Fedora and similar projects is
not made by telling people what they are doing wrong, but by
doing The Right Thing™ yourself or in collaboration with
others.  And even if one is reporting a fault, there are
ways to enable someone to fix that fault and there ways to
overwhelm them with superfluous information that makes their
work harder.

For example, take the first line of your text I quoted
above.  I can tell you that you used "with" there twice, or
I can hide that nugget in a long diatribe about the English
language, HTML mail and whatever.  If your time is limited,
you will probably prefer one over the other.

Or, to paraphrase perlstyle(1): Be explicit.  Be concise.  Be
nice.

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Tomasz Kłoczko 
On 29 January 2018 at 19:06, Igor Gnatenko  wrote:
[..]

> > As now with file trigger changes are committed and new glibc packages
> will
> > be in rawhide repo it should be mass change removing all ldconfig
> execution
> > from **ALL** Fedora specs.
>
> While I agree that this is needed, why do you point on this here? I mean
> it's
> obvious to everyone that this should be done. No need to point on obvious
> things.
>

Because similar changes even this one which you only recently started never
have been finished.
Don't get me wrong. You are doing great job. Method used so far in Fedora
are only wrong ..

I'm only asking to finish first what already have been started before you
will put on uour desk next mass change.

Also, are you interested to just write on ML what other people should do or
> you
> want to help? If former, then please stop (because it is just disturbing
> and
> not friendly). If latter, I'm happily will use script you have or you are
> going
> to write.
>

I've already wrote you in the ticket about remove icons caches updates that
remove desktop file cashes does not make any sense to start before remove
icons theme caches will be finished because quite often those updates are
in line above or below.
I'm simple waiting with raise next MCRs until prev changes will be finished.

I cannot help you on those changes because I have no proven packager privs.
If on next MCR you want me to deliver you list of patches and list of files
which needs to be applied on exact packages please do not force me or
people like me to do update those parches because someone else just after
generate thse patches made next batch of some past MCR changes still not
finishing those changes across all no touched specs.

As I wrote already I have at least few tenths other MCRs to discuss and
introduce but I refuse to cooperate in conditions when none of those
changes will be not really done from top to bottom. Is it now clear?
This is not about me or you. This is about GENERAL METHODOLOGY!!
We can do more together but you cannot just drop one change in the middle
and go to start another one ..
So again: please finish at lease PR 736 before you will start with ldconfig
to allow me start preparing next MCR when you will be working on ldconfig.

If you are taking care if exact MCR please clean everything around with
documentation and for example update rpmlint as well.
Such MCR coordinator does not need to do everything. Other people may help
him/her but this person should be at least coordinating everything and at
the and whole MCR checklist is in finished state.

This is like with with problems on taking care of the production issues or
faults.
Always needs to be someone who is controlling whole situation but this
person does not need to to person doing all OS, HW, app, db related things
which needs to be changed.
At the end such person in bigger organisation sometimes is taking
responsibility to teach other technical personnel about how to prevent
similar faults.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-29 at 18:49 +, Tomasz Kłoczko wrote:
> On 29 January 2018 at 17:18, Florian Weimer  wrote:
> 
> > Igor committed a change to glibc so that from Fedora 28 going forward,
> > glibc will run ldconfig after the transaction if any of the library
> > directory trees was modified.
> > 
> > This means that libraries which package the lib*.so.* symbolic links will
> > no longer have to run ldconfig in %postin/%postun, and we can automate the
> > creation of those symbolic links with a buildroot policy hook, see:
> > 
> >   
> > 
> > Packages which edit ld.so search paths will still have to run ldconfig in
> > %postin/%postun, as before.
> 
> 
> As now with file trigger changes are committed and new glibc packages will
> be in rawhide repo it should be mass change removing all ldconfig execution
> from **ALL** Fedora specs.

While I agree that this is needed, why do you point on this here? I mean it's
obvious to everyone that this should be done. No need to point on obvious
things.

Also, are you interested to just write on ML what other people should do or you
want to help? If former, then please stop (because it is just disturbing and
not friendly). If latter, I'm happily will use script you have or you are going
to write.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvcMkACgkQaVcUvRu8
X0zJYg//SRQTzH5njmIlCtAzTNE0I9TB/TDAzf0pQOZ2uTJgrz1jp7TMod0CJm5q
c20cBAEvJSVESS9kLvZxHVsv8k8gB5kIn85lc3miXvu1NUZbZy/K+ENw/twINkZG
v/mXkVeofSUWvo5qH40LV1KT0GgRPFiczZ9GLMos+GMtRFmky6LtfG/CE8NS0GS2
MH3ogWMIa4trVN+a+qqslaV8CuWhibOKlBMmhGlJFJL+Wg65qlkya8uOwtHWyri7
/a5BLoIt4Tx7zR6DgHLfz0Xv6QvcxzpD8E8OTs8mC+dNaQ+OEaGe7GstwUUgdDFH
TGJEX74Up7xFc6ebrlacj0U27kftAVL+XAdPVAcEox5ASDojOzmaTtMJy2hfev2b
nR1BXV/a2bEgdezM7rFeKCvf6olU+5OeZoNJJpVhkWGbmcOiBx4QWF9Ynow14Z3r
wJ0yCteh7uAqypZzQsPZ5fFuLb6SiWQ+mXcfxeO1+jLk1EjNyD9MYK5kZ4rGTFFt
ORUb0LGCZOAQ7KtXbP/ulEaNrw34rCyCF8xaHwGYFtrDUbx63YfDZ7nE1SLwNJzn
/UKUeG/j34L0T52Sy1Ntk3XuEhns/Yw1jTA95iLwaufQ7z1TCBS/cX/JqKX7DO1D
DuDXUMQoZwTUtDs4gF2kxZFSfBlrt9LrqII0/g6rEPQaSfGY83Y=
=pj/r
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-29 at 18:49 +, Tomasz Kłoczko wrote:
> On 29 January 2018 at 17:18, Florian Weimer  wrote:
> 
> > Igor committed a change to glibc so that from Fedora 28 going forward,
> > glibc will run ldconfig after the transaction if any of the library
> > directory trees was modified.
> > 
> > This means that libraries which package the lib*.so.* symbolic links will
> > no longer have to run ldconfig in %postin/%postun, and we can automate the
> > creation of those symbolic links with a buildroot policy hook, see:
> > 
> >   
> > 
> > Packages which edit ld.so search paths will still have to run ldconfig in
> > %postin/%postun, as before.
> 
> 
> As now with file trigger changes are committed and new glibc packages will
> be in rawhide repo it should be mass change removing all ldconfig execution
> from **ALL** Fedora specs.
> 
> [tkloczko@domek SPECS.fedora]$ grep -e '^%post.*/sbin/ldconfig' * | awk
> -F\. '{print $1}' | uniq | wc -l
> 3257
> [tkloczko@domek SPECS.fedora]$ grep -e ' */sbin/ldconfig' * | awk -F\.
> '{print $1}' | uniq | wc -l
> 3432
> 
> And as well:
> 
> [tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
> > wc -l
> 
> 125
> [tkloczko@domek SPECS.fedora]$ grep -e '^Requires(postun):.*/sbin/ldconfig'
> * |wc -l
> 114
> 
> This needs to be removed as well. If not it will be like with for example
> in hicolor-icon-theme.spec after remove %post/%postun/%postrans
> with gtk-update-icon-cache execution still is possible to find in this spec:

Redmining you 1000th time, don't mix issues. This thread is **ONLY about
ldconfig**.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvb0YACgkQaVcUvRu8
X0wknxAAq3lIUPqHp86ANwS3fw3jlJBdCXjTNRVuxENg+1RsmC9ABNyxeig87o89
6t45hJSPA6Jq7w5DbTrNOm4Qpxw1ldRHeWxp6yxJw6qmmB8egPwrK20FzjQ1gELN
i+IoaQ2lu3aLS1VQBsEAiCYPco/Vw5JxRHge3AqzS4lS9VChH+wadfchjZAnWDv1
Q5etY2LP9P1qe0G0HnCKAPOQPQH4b0BAuRA6OTjaSRpahD/JKHsZDJHFOkVx9vEL
yshsAnwM2oiapUieytc1svEwQVd87DD/Wn3S0TbRynUALacz25X0xpfnRLwZLMBm
kiES8tCMBwesmoLwsuZhBSWM8VQYVqOfJ6EI1GRByj8p/tFMu44QduzgOqNJ8qKF
vyk0xJ0aTCXrux6Z42aPWBZJeQAz7TUHUeTUbyJxdeqPwZJkRx9vxgommcBIjN1u
P7sopGuFRLZfldut3DABtlwuiFDbQo4QZqPQaApLM6z4o7u5WURkLYvP9g1Qvuha
LLftGqm/JpOtNcLz2FbP+MP4aa8t5vky2TdwpBkKNv2DWcKu2XjeQm67GzA4Rp9N
kNzk39wEfECCL3hQN9/ah4MZzjb8DXbbXoPo/sIPOA8dQZFf84DxJXggLnzoiIW+
IpbJS+tjYKUt6bfsNKeVp3CA198YDhkjXTZlntKEXeTxCEumDRs=
=aJ8N
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Tomasz Kłoczko 
On 29 January 2018 at 17:18, Florian Weimer  wrote:

> Igor committed a change to glibc so that from Fedora 28 going forward,
> glibc will run ldconfig after the transaction if any of the library
> directory trees was modified.
>
> This means that libraries which package the lib*.so.* symbolic links will
> no longer have to run ldconfig in %postin/%postun, and we can automate the
> creation of those symbolic links with a buildroot policy hook, see:
>
>   
>
> Packages which edit ld.so search paths will still have to run ldconfig in
> %postin/%postun, as before.


As now with file trigger changes are committed and new glibc packages will
be in rawhide repo it should be mass change removing all ldconfig execution
from **ALL** Fedora specs.

[tkloczko@domek SPECS.fedora]$ grep -e '^%post.*/sbin/ldconfig' * | awk
-F\. '{print $1}' | uniq | wc -l
3257
[tkloczko@domek SPECS.fedora]$ grep -e ' */sbin/ldconfig' * | awk -F\.
'{print $1}' | uniq | wc -l
3432

And as well:

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
|wc -l
125
[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(postun):.*/sbin/ldconfig'
* |wc -l
114

This needs to be removed as well. If not it will be like with for example
in hicolor-icon-theme.spec after remove %post/%postun/%postrans
with gtk-update-icon-cache execution still is possible to find in this spec:

Requires(post): coreutils
Requires(postun): coreutils


If all those changes will be not it will be like with other such changes
which never have been finished:

[tkloczko@domek SPECS.fedora]$ grep '^%clean' * | wc -l
3007
[tkloczko@domek SPECS.fedora]$ grep '^BuildRoot:' * | wc -l
2746
[tkloczko@domek SPECS.fedora]$ grep '^Group:' * | wc -l
18065

To be hones I would be personally [1] way happier if Igor will finish first
finish remove hicolor icons theme cache update before jumping on ldconfig.

Just please Igor (or anyone else who will be helping him) do this properly
finishing whole set of necessary changes within as short as it is only
possible time.

Next point which someone needs to take care is update rpmlint to generate
warning that use ldconfig in %post/%postun is no longer needed.


 And yet another thing connected with above.

I've been many times proposing to use in specs single package/file name
name in each Reqiure or BuildRequires.
I know that many packages do not like this because they are already using
other style.
However it is not about what me or someone else may or may not prefer.
Using single package per Reqiure or BuildRequires is not a matter of
personal preferences because if all those Reqiure/BuildRequires will be
with single package or file path all mass changes will be *way easier to do* by
simple "sed -ie 'd,^Requires(post):.*/sbin/ldconfig,' *spec"

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
acl.spec:Requires(post): /sbin/ldconfig
alsa-lib.spec:Requires(post): /sbin/ldconfig, coreutils
blitz.spec:Requires(post): /sbin/install-info /sbin/ldconfig
cfitsio.spec:Requires(post):/sbin/ldconfig
cinnamon-session.spec:Requires(post): /sbin/ldconfig
Coin2.spec:Requires(post): /sbin/ldconfig
Coin3.spec:Requires(post): /sbin/ldconfig
concordance.spec:Requires(post): /sbin/ldconfig
cyrus-imapd.spec:Requires(post): /sbin/ldconfig
dapl.spec:Requires(post): /sbin/ldconfig
ddccontrol.spec:Requires(post):   /sbin/ldconfig
drumstick0.spec:Requires(post): /sbin/ldconfig
drumstick.spec:Requires(post): /sbin/ldconfig
eb.spec:Requires(post): /sbin/ldconfig
eventlog.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
firebird.spec:Requires(post):   /sbin/ldconfig
firebird.spec:Requires(post):   /sbin/ldconfig
freehdl.spec:Requires(post): /sbin/install-info /sbin/ldconfig
fwknop.spec:Requires(post): /sbin/ldconfig
gauche.spec:Requires(post): /sbin/install-info, /sbin/ldconfig
gconfmm26.spec:Requires(post):   /sbin/ldconfig
geda-gaf.spec:Requires(post):   /sbin/ldconfig
gerbv.spec:Requires(post):   /sbin/ldconfig
getdata.spec:Requires(post):/sbin/ldconfig
gnucash.spec:Requires(post): /sbin/ldconfig
gnumeric.spec:Requires(post):   /sbin/ldconfig
gr-air-modes.spec:Requires(post):   /sbin/ldconfig
graphviz.spec:Requires(post): /sbin/ldconfig
graphviz.spec:Requires(post): %{_bindir}/dot /sbin/ldconfig
gr-fcdproplus.spec:Requires(post):   /sbin/ldconfig
gr-iqbal.spec:Requires(post):   /sbin/ldconfig
groonga.spec:Requires(post): /sbin/ldconfig
gr-osmosdr.spec:Requires(post):   /sbin/ldconfig
gtkglextmm.spec:Requires(post): /sbin/ldconfig
gtkglext.spec:Requires(post): /sbin/ldconfig
gwenhywfar.spec:Requires(post): /sbin/ldconfig
hylafax+.spec:Requires(post): /sbin/ldconfig
infiniband-diags.spec:Requires(post): /sbin/ldconfig
infinipath-psm.spec:Requires(post):   /sbin/ldconfig
infinipath-psm.spec:Requires(post):   /sbin/ldconfig
k3d.spec:Requires(post):

Re: RPM packaging and ldconfig handling

2018-01-29 Thread Florian Weimer 
Igor committed a change to glibc so that from Fedora 28 going forward, 
glibc will run ldconfig after the transaction if any of the library 
directory trees was modified.


This means that libraries which package the lib*.so.* symbolic links 
will no longer have to run ldconfig in %postin/%postun, and we can 
automate the creation of those symbolic links with a buildroot policy 
hook, see:


  

Packages which edit ld.so search paths will still have to run ldconfig 
in %postin/%postun, as before.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-15 Thread Tomasz Kłoczko 
On 15 January 2018 at 12:42, Florian Weimer  wrote:
> On 01/15/2018 05:40 AM, Tomasz Kłoczko wrote:
>> Currently /sbin/ldconfig is part of the glibc package.
>> Depends which one package was installed/updated firs and which one
>> second system image end ups with 32 or 64 bits /sbin/ldconfig.
>> Depends which one binary will be present ldconfig by default goes over
>> /lib or /lib64 directories + any other directories specified in
>> /etc/ld.so,conf.d/  files.
>
>
> I believe this part at least is not technically accurate, see
> sysdeps/unix/sysv/linux/x86_64/dl-cache.h in the glibc sources.  x86-64
> ldconfig processes the lib and libx32 directories as well.

Just double checked this and you are right.
I've been doing my test when I had no installed any i686 package and
in case like this such test result looks a bit misleading:

[root@domek]# strace -e trace=file ldconfig 2>&1 | grep -v lib64
execve("/sbin/ldconfig", ["ldconfig"], 0x7ffe8c9d4260 /* 35 vars */) = 0
readlink("/proc/self/exe", "/usr/sbin/ldconfig", 4096) = 18
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.conf.d",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/atlas-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/bind99-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/community-mysql-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.13.9-300.fc27.x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.14.11-300.fc27.x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.15.0-0.rc7.git0.1.fc28.x86_64.conf",
O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.15.0-0.rc7.git2.1.fc28.x86_64.conf",
O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/libiscsi-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/wine-64.conf", O_RDONLY) = 4
stat("/lib", {st_mode=S_IFDIR|0555, st_size=804, ...}) = 0
stat("/libx32", 0x7ffd776af490) = -1 ENOENT (No such file or directory)
stat("/usr/lib", {st_mode=S_IFDIR|0555, st_size=804, ...}) = 0
stat("/usr/libx32", 0x7ffd776af490) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/cache/ldconfig/aux-cache", O_RDONLY) = 3
openat(AT_FDCWD, "/lib", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
lstat("/lib/sse2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
openat(AT_FDCWD, "/lib/sse2", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache~",
O_WRONLY|O_CREAT|O_TRUNC|O_NOFOLLOW, 0600) = 3
chmod("/etc/ld.so.cache~", 0644)= 0
rename("/etc/ld.so.cache~", "/etc/ld.so.cache") = 0
stat("/var/cache/ldconfig", {st_mode=S_IFDIR|0700, st_size=18, ...}) = 0
openat(AT_FDCWD, "/var/cache/ldconfig/aux-cache~",
O_WRONLY|O_CREAT|O_TRUNC|O_NOFOLLOW, 0600) = 3
rename("/var/cache/ldconfig/aux-cache~", "/var/cache/ldconfig/aux-cache") = 0
+++ exited with 0 +++

After install glibc.i686 after stat() for /lib of course in above
output is new set of lines open()ing all libs in /lib.

Original (small) issue with place separated file triggers for /lib,
/ust/lib64 in 64 bit glibc and /lib, /usr/lib in 32 bit glibc packages
still is real because in such case
with installed two packages like glibc.{i686,x86_64} such separation
will cause that those file triggers will be called two times doing
*exactly* the same things in both cases.
It is not a big deal because with remove all per package
/sbin/ldconfig executions still it will save a lot of time .. however
fact is fact.
I've mentioned this duplicated execution only for the record and IMO
this can be ignored.

However still I think that the best solution would be drop use ld.so caches.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-15 Thread Florian Weimer 

On 01/15/2018 05:40 AM, Tomasz Kłoczko wrote:

Currently /sbin/ldconfig is part of the glibc package.
Depends which one package was installed/updated firs and which one
second system image end ups with 32 or 64 bits /sbin/ldconfig.
Depends which one binary will be present ldconfig by default goes over
/lib or /lib64 directories + any other directories specified in
/etc/ld.so,conf.d/  files.


I believe this part at least is not technically accurate, see 
sysdeps/unix/sysv/linux/x86_64/dl-cache.h in the glibc sources.  x86-64 
ldconfig processes the lib and libx32 directories as well.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

2018-01-14 Thread Tomasz Kłoczko 
On 14 January 2018 at 23:32, Neal Gompa  wrote:
[..]
>> I think that at least someone in glibc team should start to consider
>> drop completely use ld.so.cache.
>> This "speedup" mechanism was invented more than two decades ago when
>> it was the problem with VFS layer caching.
>> The same "loading time issues" have been driving in latex use kpathsea.
>> Both techniques today are more or less **obsolete**.
>>
>
> I'm not sure you're aware of this, but the GNU C Library serves more
> than Linux. While Linux VFS is much better than it was 20 years ago,
> other OSes are not necessarily so.

1) I'm not sure are you aware that C preprocessor (cpp) provides
possibility to use (or not) some parts of the C code conditionally
depends on OS type
2) Could you please name operating systems on which glibc is used NOW
which has no VFS or VFS like caching layer?
Linux has it.

We are trying discuss how to solve some Linux and rpm as package manager issues.
Please stick to this context only. We don't need to solve here Earth
famine problems (at least for now).

[..]
>> BTW it is yet another small issue with those file triggers.
>> Build process described in glibc.spec build 32 or 64 bits versions of
>> the binaries.
>> ldconfig is part of the main glbc package and it is possible on x86
>> install glibc.i386 and glibc.x86_64
>> When both ABI versions packages are installed those file triggers will
>> be executed two times.
>
> This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.

Nope. File triggers are using base paths. You cannot specify as the
parameters of those triggers /%{_lib}/lib*.so.* and
%{_libdir}/lib*.so.*
BTW: currently  /%{_lib} and %{_libdir} are the same so only
%{_libdir} needs to be used.

$ ls -ld {,/usr}/lib{,64}
lrwxrwxrwx  1 root root  7 Dec 14 17:14 /lib -> usr/lib
lrwxrwxrwx  1 root root  9 Dec 14 17:14 /lib64 -> usr/lib64
dr-xr-xr-x. 1 root root804 Jan  9 13:08 /usr/lib
dr-xr-xr-x. 1 root root 109892 Jan 14 03:21 /usr/lib64

In your case still rpm triggers semantics needs to changed or new
triggers type needs to be introduced.
In solution which I've described none of new code in rpm needs to be added.

Currently /sbin/ldconfig is part of the glibc package.
Depends which one package was installed/updated firs and which one
second system image end ups with 32 or 64 bits /sbin/ldconfig.
Depends which one binary will be present ldconfig by default goes over
/lib or /lib64 directories + any other directories specified in
/etc/ld.so,conf.d/ files.
To handle this case correctly it would be necessary to introduce
/sbin/ldconfig-{32,64} duplicate configuration files an not only
/etc/ld.so.cache but as well /var/cache/ldconfig/aux-cache file.

Just made some experiment:

[root@domek]# rpm -qf /sbin/ldconfig
glibc-2.26.9000-38.fc28.x86_64
[root@domek]# file /sbin/ldconfig
/sbin/ldconfig: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=d6c3aae1d69c4ae9fe307ab58bbd2bc3f892bf38, not stripped
[root@domek]# dnf install -y glibc.i686
Last metadata expiration check: 2:47:52 ago on Mon 15 Jan 2018 01:15:04 GMT.
[..]

Installed:
  glibc.i686 2.26.9000-38.fc28

Complete!

[root@domek]# file /sbin/ldconfig
/sbin/ldconfig: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=d6c3aae1d69c4ae9fe307ab58bbd2bc3f892bf38, not stripped
[root@domek]# rpm -qf /sbin/ldconfig
glibc-2.26.9000-38.fc28.x86_64
[root@domek]# rpm -ql glibc.i686 | grep /sbin/ldconfig
/sbin/ldconfig
[root@domek]# rpm -ql glibc.x86_64 | grep /sbin/ldconfig
/sbin/ldconfig

This /sbin/ldconfig only is looking for libraries to index in /lib64.
With both glibc installed only 32 or 64 bit will be indexed does't
matter if in both glibcs will be file trigger only for /lib or /lib
and /lib64 or any other combinations of the paths.

In scenario which I've presented none of those things will happen
because it would be no ld.so.cache which context needs to be
maintained.
In your case to handle 32/64 ABI shared env it will be necessary to
introduce some number of new C code when in in my case complete
solution will consist almost entirely from only *remove existing code*
and on packaging layer remove (only) all ldconfig executions in rpm
scriplets.
(Again: .. Ockham Razor)

I can only repeat that after more than two decades when ld.so.cache
has been introduced now using this file only slows down run-time
linking.

>> All this is result another rpm weakness that all global actions (aka
>> in rpm semantics triggers) must be defined not package manager set of
>> the trigger but only in packages.
>
> It's pretty trivial to do that behavior. For example, we could just
> have a posttrans trigger that runs a program that decides all the
> things based on what the filesystem looks like (Solus does this with
> usysconf[1]). But that means the tool needs to know how to decide what
> to run.
>
> [1]:

Re: RPM packaging and ldconfig handling

2018-01-14 Thread Neal Gompa 
On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko
 wrote:
> On 14 January 2018 at 16:38, Igor Gnatenko
>  wrote:
>> On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
>>> The glibc team has received a request to change the way ldconfig
>>> invocations during package installations and deinstallations are handled.
>>>
>>> https://src.fedoraproject.org/rpms/glibc/pull-request/5
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1380878
>>>
>>> Some background: ldconfig serves several functions.  Key aspects are:
>>>
>>> 1. Speed up programing loading.
>
> I think that at least someone in glibc team should start to consider
> drop completely use ld.so.cache.
> This "speedup" mechanism was invented more than two decades ago when
> it was the problem with VFS layer caching.
> The same "loading time issues" have been driving in latex use kpathsea.
> Both techniques today are more or less **obsolete**.
>

I'm not sure you're aware of this, but the GNU C Library serves more
than Linux. While Linux VFS is much better than it was 20 years ago,
other OSes are not necessarily so.

> Other Unixes like BSD* and Solaris instead focusing on ld.so latency
> started improving VFS caching and results now are equal from point of
> view of execution latency
> None of the BSD* or Solaris ld.so are using not using any ld.so. cache
> and are using only more sophisticated configuration framework which
> allows, for example, mask not use exact file which provides SONAME to
> use another one which provides such SONAME from the non-standard
> paths.
> As result ld.so is not forced to load few hundreds KB cache file, it
> stat()s and open()s blindly / file relaying 100% of
> VFS.
>
> In other words instead of fighting with the fact that below
> {,/usr}/lib{,64} or another subset of cases would be possible to drop
> use ldconfig, simplify ld.so and at the end remove all %post/%postun
> /sbin/ldconfig execution.
> Instead, all of this could be introduced crle command like on Solaris.
>
> crle man page 
> https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
>
> Performance of the not use cache is easy to test by simple remove
> /etc/ld.so.cache and observe ld.so by executing "LD_DEBUG=statistics
> ".
> Example:
>
> $ LD_DEBUG=statistics ls -d /etc
>  23174:
>  23174: runtime linker statistics:
>  23174:   total startup time in dynamic loader: 6135538 cycles
>  23174: time needed for relocation: 2876398 cycles (46.8%)
>  23174:  number of relocations: 629
>  23174:   number of relocations from cache: 3
>  23174: number of relative relocations: 1582
>  23174:time needed to load objects: 2304750 cycles (37.5%)
> /etc
>
> If those statistics will be not enough probably other people will
> propose  other/better method showing that using ld.so.cache still is
> necessary or could be dropped.
>
> Solaris crle man page
> https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
>
> [..]
>>> The latest proposal has this change for the glibc spec file, in order to
>>> deal with the issue of item 2:
>>>
>>> # File triggers for when libraries are added or removed in standard paths
>>> %transfiletriggerin -p /sbin/ldconfig -P 200 -- /lib /usr/lib /lib64
>>> /usr/lib64
>>>
>>> %transfiletriggerpostun -p /sbin/ldconfig -P 200 -- /lib /usr/lib
>>> /lib64 /usr/lib64
>
> BTW it is yet another small issue with those file triggers.
> Build process described in glibc.spec build 32 or 64 bits versions of
> the binaries.
> ldconfig is part of the main glbc package and it is possible on x86
> install glibc.i386 and glibc.x86_64
> When both ABI versions packages are installed those file triggers will
> be executed two times.

This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.

> All this is result another rpm weakness that all global actions (aka
> in rpm semantics triggers) must be defined not package manager set of
> the trigger but only in packages.

It's pretty trivial to do that behavior. For example, we could just
have a posttrans trigger that runs a program that decides all the
things based on what the filesystem looks like (Solus does this with
usysconf[1]). But that means the tool needs to know how to decide what
to run.

[1]: https://github.com/solus-project/usysconf

> Just for the compare .. IPS has the strict and finite set of analogues
> of the triggers called actions.
> ***NONE*** of the packages definitions contains any actions
> definitions and all works perfectly causing that whoever is
> responsible for building packages has no opportunity to mess in this
> area BY DEFINITION.
> BTW .. IPS has no at all possibility to add any post/postun/trans
> scripts. IMO it is only matter of time when rpm developers will spot
> that all this stuff in spec files is only constant source of problems.
> People moving away from SySV packages which

Re: RPM packaging and ldconfig handling

2018-01-14 Thread Tomasz Kłoczko 
On 14 January 2018 at 16:38, Igor Gnatenko
 wrote:
> On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
>> The glibc team has received a request to change the way ldconfig
>> invocations during package installations and deinstallations are handled.
>>
>> https://src.fedoraproject.org/rpms/glibc/pull-request/5
>> https://bugzilla.redhat.com/show_bug.cgi?id=1380878
>>
>> Some background: ldconfig serves several functions.  Key aspects are:
>>
>> 1. Speed up programing loading.

I think that at least someone in glibc team should start to consider
drop completely use ld.so.cache.
This "speedup" mechanism was invented more than two decades ago when
it was the problem with VFS layer caching.
The same "loading time issues" have been driving in latex use kpathsea.
Both techniques today are more or less **obsolete**.

Other Unixes like BSD* and Solaris instead focusing on ld.so latency
started improving VFS caching and results now are equal from point of
view of execution latency
None of the BSD* or Solaris ld.so are using not using any ld.so. cache
and are using only more sophisticated configuration framework which
allows, for example, mask not use exact file which provides SONAME to
use another one which provides such SONAME from the non-standard
paths.
As result ld.so is not forced to load few hundreds KB cache file, it
stat()s and open()s blindly / file relaying 100% of
VFS.

In other words instead of fighting with the fact that below
{,/usr}/lib{,64} or another subset of cases would be possible to drop
use ldconfig, simplify ld.so and at the end remove all %post/%postun
/sbin/ldconfig execution.
Instead, all of this could be introduced crle command like on Solaris.

crle man page 
https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html

Performance of the not use cache is easy to test by simple remove
/etc/ld.so.cache and observe ld.so by executing "LD_DEBUG=statistics
".
Example:

$ LD_DEBUG=statistics ls -d /etc
 23174:
 23174: runtime linker statistics:
 23174:   total startup time in dynamic loader: 6135538 cycles
 23174: time needed for relocation: 2876398 cycles (46.8%)
 23174:  number of relocations: 629
 23174:   number of relocations from cache: 3
 23174: number of relative relocations: 1582
 23174:time needed to load objects: 2304750 cycles (37.5%)
/etc

If those statistics will be not enough probably other people will
propose  other/better method showing that using ld.so.cache still is
necessary or could be dropped.

Solaris crle man page
https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html

[..]
>> The latest proposal has this change for the glibc spec file, in order to
>> deal with the issue of item 2:
>>
>> # File triggers for when libraries are added or removed in standard paths
>> %transfiletriggerin -p /sbin/ldconfig -P 200 -- /lib /usr/lib /lib64
>> /usr/lib64
>>
>> %transfiletriggerpostun -p /sbin/ldconfig -P 200 -- /lib /usr/lib
>> /lib64 /usr/lib64

BTW it is yet another small issue with those file triggers.
Build process described in glibc.spec build 32 or 64 bits versions of
the binaries.
ldconfig is part of the main glbc package and it is possible on x86
install glibc.i386 and glibc.x86_64
When both ABI versions packages are installed those file triggers will
be executed two times.
All this is result another rpm weakness that all global actions (aka
in rpm semantics triggers) must be defined not package manager set of
the trigger but only in packages.
Just for the compare .. IPS has the strict and finite set of analogues
of the triggers called actions.
***NONE*** of the packages definitions contains any actions
definitions and all works perfectly causing that whoever is
responsible for building packages has no opportunity to mess in this
area BY DEFINITION.
BTW .. IPS has no at all possibility to add any post/postun/trans
scripts. IMO it is only matter of time when rpm developers will spot
that all this stuff in spec files is only constant source of problems.
People moving away from SySV packages which implemented IPS come to
this brilliant observation DECADE ago. It may take on Linux next
decade to "reinvent the wheel" but I'm 100% that all those scripts
embedded in packages sooner or later will be removed.

Conclusion: so far I've been actively supporting add glibc file
triggers by trying to add my comments discussion in bugzilla tickets.
However, as I have in my head quite deep knowledge of other operating
systems recently I found  see now WAY better solution which does not
increases current entropy and/or is Ockham Razor compliant solution
(https://en.wikipedia.org/wiki/Occam%27s_razor)

So again this solution should consist of:
- remove use ld.so,cache by ld.so
- remove ldconfig and all /sbin/ldconfig in all spec files
- add crle or crle like command (knowing Linux NIH probably it will
end up on crle like command)

BTW:

Re: RPM packaging and ldconfig handling

2018-01-14 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
> The glibc team has received a request to change the way ldconfig 
> invocations during package installations and deinstallations are handled.
> 
> https://src.fedoraproject.org/rpms/glibc/pull-request/5
> https://bugzilla.redhat.com/show_bug.cgi?id=1380878
> 
> Some background: ldconfig serves several functions.  Key aspects are:
> 
> 1. Speed up programing loading.
> 
> 2. Enable the dynamic linker to load libraries by their soname.
> 
> 3. Enable the dynamic linker to load libraries in directories listed in 
> /etc/ld.so.conf and /etc/ld.so.conf.d.
> 
> The first point is a performance issue and does not matter in this 
> context.  Item 2 and 3, however, can cause program invocation to fail if 
> ldconfig is not run and certain changes are made to the system.
> 
> The Packaging Guidelines currently require that packages must call 
> ldconfig if they install or install shared objects:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
> 
> I assume that the goal of the proposal is to reduce both maintainer 
> overhead and speed up package installation, by removing the ldconfig 
> invocations from individual packages.  This is indeed worthwhile.
> 
> However, we need to make sure that when subsequent RPM scriptlets are 
> executed after the installation or update of a shared object, they see a 
> system which is usable, so that they can run all the programs listed in 
> the RPM dependencies.
> 
> The latest proposal has this change for the glibc spec file, in order to 
> deal with the issue of item 2:
> 
> # File triggers for when libraries are added or removed in standard paths
> %transfiletriggerin -p /sbin/ldconfig -P 200 -- /lib /usr/lib /lib64 
> /usr/lib64
> 
> %transfiletriggerpostun -p /sbin/ldconfig -P 200 -- /lib /usr/lib 
> /lib64 /usr/lib64
> 
> But this will run at the end of the transaction, which is too late for 
> other scriptlets (which, for %post, run immediately after unpacking an 
> RPM package).

We can switch it to %filetrigger* at least for beginning in order to stop
asking people to write /sbin/ldconfig manually. Effect will be same, but at
least it will not put work on packagers heads.

> It would not be a good idea to turn the triggers into %filetriggerin and 
> %filetriggerun, in my opinion.  They would run after the installation of 
> the package, but since the paths specify entire directory trees, the 
> trigger would fire for the installation of many noarch packages to due 
> to the /usr/lib path (e.g., Python packages are installed into 
> /usr/lib/python*/site-packages/bugzilla).

It is possible to filter files in scriptlets to not run it on random files.

> We can still skip running ldconfig if we can otherwise make sure that 
> the symbolic links for the DSO sonames are available, so that we simply 
> have a minor performance issue.  ldconfig would still have to be run by 
> %transfiletriggerin and %transfiletriggerpostun to optimize the system, 
> but the precise point at time when this has to happen does not matter, 
> except that it should happen after RPM removed all files to be deleted 
> during the RPM transaction (which generally happens toward the end, 
> during the cleanup phase, and not immediately after the installation of 
> a different package version).  As far as I can tell, even with a 
> successful cache lookup, the dynamic loader still uses the soname 
> symbolic link to open the DSO file, so renaming the implementation name 
> (say, for libc-2.25.so to libc-2.26.so) would not lead to temporary 
> breakage.
> 
> We would however make sure that at RPM packaging time, the symbolic 
> links are created automatically (otherwise the goal of reducing 
> maintainer overhead would not be met).

As Neal mentioned, it should be possible with very simple brp script.

> For item 3 (shared objects in non-default directories), I think the 
> proposed change for the glibc:
> 
> %filetriggerin -p /sbin/ldconfig -P 200 -- /etc/ld.so.conf.d
> %filetriggerun -p /sbin/ldconfig -P 200 -- /etc/ld.so.conf.d
> 
> should work in most cases, except when the configuration file is in a 
> separate -common package which might not be (un)installed before or 
> after the package which contains the DSO file (so that the automatic 
> ldconfig invocation does not happen at the right point in time). 
> However, these packages are rare, so perhaps it would be preferable to 
> keep the explicit ldconfig invocations in the packages for explicitness 
> (and generally discourage the use of non-default search paths).
> 
> For all these triggers, we need to carefully consider the -P priority 
> value and document it in the Packaging Guidelines.

As Jason pointed, he doesn't see value of having priority documented in
guidelines, it is just some value chosen by glibc (or, rather, by person who
sent PR)..

> In any case, I don't think we can just make a

Re: RPM packaging and ldconfig handling

2018-01-14 Thread Neal Gompa 
On Fri, Jan 12, 2018 at 9:00 AM, Florian Weimer  wrote:
> The glibc team has received a request to change the way ldconfig invocations
> during package installations and deinstallations are handled.
>
> https://src.fedoraproject.org/rpms/glibc/pull-request/5
> https://bugzilla.redhat.com/show_bug.cgi?id=1380878
>
> Some background: ldconfig serves several functions.  Key aspects are:
>
> 1. Speed up programing loading.
>
> 2. Enable the dynamic linker to load libraries by their soname.
>
> 3. Enable the dynamic linker to load libraries in directories listed in
> /etc/ld.so.conf and /etc/ld.so.conf.d.
>
> The first point is a performance issue and does not matter in this context.
> Item 2 and 3, however, can cause program invocation to fail if ldconfig is
> not run and certain changes are made to the system.
>
> The Packaging Guidelines currently require that packages must call ldconfig
> if they install or install shared objects:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
>
> I assume that the goal of the proposal is to reduce both maintainer overhead
> and speed up package installation, by removing the ldconfig invocations from
> individual packages.  This is indeed worthwhile.
>
> However, we need to make sure that when subsequent RPM scriptlets are
> executed after the installation or update of a shared object, they see a
> system which is usable, so that they can run all the programs listed in the
> RPM dependencies.
>
> The latest proposal has this change for the glibc spec file, in order to
> deal with the issue of item 2:
>
> # File triggers for when libraries are added or removed in standard paths
> %transfiletriggerin -p /sbin/ldconfig -P 200 -- /lib /usr/lib /lib64
> /usr/lib64
>
> %transfiletriggerpostun -p /sbin/ldconfig -P 200 -- /lib /usr/lib /lib64
> /usr/lib64
>
> But this will run at the end of the transaction, which is too late for other
> scriptlets (which, for %post, run immediately after unpacking an RPM
> package).
>
> It would not be a good idea to turn the triggers into %filetriggerin and
> %filetriggerun, in my opinion.  They would run after the installation of the
> package, but since the paths specify entire directory trees, the trigger
> would fire for the installation of many noarch packages to due to the
> /usr/lib path (e.g., Python packages are installed into
> /usr/lib/python*/site-packages/bugzilla).
>

The fact that noarch Python site-packages exist in /usr/lib has always
bugged me. I don't know why it's that way or if there's something that
can be done about it in Fedora and upstream to move them to /usr/share.

But I don't think it's the only ecosystem like that, which is why they
are %transfiletriggers.

That said, in the nearly 10 years that the Mandriva family has been
using file triggers for running ldconfig, it hasn't caused any major
issues. Heck, the file triggers that have been proposed are more
comprehensive than the existing ones used in Mageia, to cover things
like the usage of RemovePathPostfixes in some RPM packages as well as
dealing with packages with non-standard paths.

Honestly, the worst case scenario is that "weird" packages going into
paths like /opt/foo/baz/lib64 would need to still run ldconfig, but
that's only if they don't drop a file into /etc/ld.so.conf.d and don't
use rpaths.

> We can still skip running ldconfig if we can otherwise make sure that the
> symbolic links for the DSO sonames are available, so that we simply have a
> minor performance issue.  ldconfig would still have to be run by
> %transfiletriggerin and %transfiletriggerpostun to optimize the system, but
> the precise point at time when this has to happen does not matter, except
> that it should happen after RPM removed all files to be deleted during the
> RPM transaction (which generally happens toward the end, during the cleanup
> phase, and not immediately after the installation of a different package
> version).  As far as I can tell, even with a successful cache lookup, the
> dynamic loader still uses the soname symbolic link to open the DSO file, so
> renaming the implementation name (say, for libc-2.25.so to libc-2.26.so)
> would not lead to temporary breakage.
>
> We would however make sure that at RPM packaging time, the symbolic links
> are created automatically (otherwise the goal of reducing maintainer
> overhead would not be met).
>

There's been a PR upstream in rpm[0] for a while now to support a more
comprehensive buildroot policy (brp) based on the Mandriva/Mageia
spec-helper[1] stuff.

One of the components of that PR is running ldconfig in the buildroot
to produce those DSO links[2].

We could pull that in and adjust redhat-rpm-config to disable the ones
we don't want. There's also an issue for making brp stuff better[3].

[0]: https://github.com/rpm-software-management/rpm/pull/122
[1]: http://gitweb.mageia.org/software/rpm/spec-helper/
[2]: