On 8/26/2019 7:22 PM, Jean-Marc Pigeon via blfs-dev wrote:
The solution, is to "hardcode" the fact glibc is gnu hash
compatible by inserting "Provides: rtld(GNU_HASH)" within
glibc spec file (a simple marker).
Not exactly. I think you've misunderstood my suggestion here. Let me try
to explain the two parts separately.
The 'solution' above was RedHat's (and later SUSE's) solution to account
for a change in glibc packages after the new hash functionality became
available. I'm a bit fuzzy on this part, but I believe it was
binutils-2.17 that provided the necessary changes in the linker to use
the new functionality in glibc (I believe it was Ken who unearthed that
bit). Ultimately, RH could not place an unneeded dependency on a
particular version of binutils when you really need files from glibc
that were built against that version of binutils, (why they didn't just
increment the build number is beyond me, maybe it was a split package at
the time or they were dependent on the soname rather than a particular
package) so the provides was added in RH/SUSE specs to make the
requirements in downstream packages explicitly require this
functionality if needed (which probably should be gone so many years
later). Your packages never had that split so likely shouldn't add that
provides workaround (unless you aim to be able to use RH/SUSE specs
without modification, but then why write your own specs?). My suggestion
for you to add the above was provided strictly as a workaround to
_avoid_ rebuilding LO and keep your existing package (since it takes
forever to build).
The problem here was always in LO. If you are already going through the
trouble of rebuilding LO to account for the other downloads, then you
should probably leave the glibc spec alone and remove the rtld
requirement from your LO spec(s) so that it uses just your package names
and versions (no need to litter the RPM DB with additional provides
data). I might be oversimplifying things a bit here, I haven't seen your
spec for LO, and it could be some automated thing that I'm unaware of,
but that's what I was trying to guide you to discover on your own in my
earlier message - precisely why I told you to "provide it" rather than
the above verbatim for that matter - which I actually wound up removing
from my first message as I though it too much hand-holding. Make you
work for it, just a little, and you'll remember for life. :-)
Does that make more sense? And that's not to say that what you've done
will not work. In fact, it should have made your existing LO rpm
installable without any rebuild or need to force it to install, and will
clearly meet the requirements for your new rpm if you've still not
modified the dependencies.
All that said, LFS and BLFS is about learning, but only to a certain
point (it has to be usable as well). There is nothing inherently wrong
with the above workaround other than it most likely being unnecessary
(and a bit unclean IMO) -- clearly RedHat and SUSE, who should be the
experts, think it's fine -- but I wanted to take the time to make sure
that you understand that the original error was not in your decision to
omit the provides in your glibc spec file, but the depends lines in LO's
spec. BTW, would you mind sharing both? It might be helpful for somebody
else later on and will most definitely answer my remaining question
about "some automated thing" above.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
