Source RPM size
by Florian Weimer
Would it concern you if the source RPM size grew to about 110 MiB?
This data would not have to be uploaded with a “fedpkg new-sources”
command for every upstream import, only once per Fedora release cycle.
Thanks,
Florian
5 years, 11 months
tarballs vs ABI xml files in dist-git.
by Carlos O'Donell
Florian,
You expressed some worry about checking in the tarballs for the frozen
ABI specification into dist-git. Really git is not designed to hold
tarballs, and the source cache is just wrong since this is not a source
tarball (we used to abuse it also for the releng tarball).
It is relatively easy to move all the files directly into dist-git, and
use a lua construct like this:
+%{lua:
+-- List all of the frozen ABI xml files as source files.
+function recursedir(directory)
+ local i, t, popen = 0, {}, io.popen
+ local pfile = popen('find "'..directory..'" -type f')
+ for filename in pfile:lines() do
+ i = i + 1
+ t[i] = filename
+ end
+ pfile:close()
+ return t
+end
+# There are almost 2000 ABI specification files.
+lines = recursedir ('releng/frozen-abi/')
+-- Last Source file is numbered 12.
+j = 12
+for i,v in ipairs(lines) do
+ print('Source'..i..': '..v)
+ j = j + 1
+end
+}
+%endif
Which generates the source line entries from the directories.
This would allow us to manually tweak the ABI files by hand and
track the changes over time as we update glibc.
Would this be a better design?
--
Cheers,
Carlos.
5 years, 11 months
[PATCH 2/2] Add formal ABI verification for all shared objects.
by Carlos O'Donell
The spec file is enhanced to allow a developer to save (save_abi=1)
the ABI of the package, and to turn on verification of the ABI
(verify_abi=1). The saved and manually inspected ABI for aarch64,
armv7hl, i686, ppc64, ppc64le, s390x, and x86_64 are also checked
in as compressed archives. When a release branch is in effect
(without the .9000 subrevision) the spec file automatically turns
ABI verification on and compares, during the install phase, the
generated ABI of the installed shared objects before stripping.
Carrying out the ABI verification at this point yields the highest
quality debug information, and least likelihood of problems. It is
expected that the distribution will do it's own rpm to rpm checking.
This ABI checking is meant as a glibc developer tool to assist in
catching ABI changes before deployment.
---
frozen-abi-aarch64.tar.xz | Bin 0 -> 235400 bytes
frozen-abi-armv7hl.tar.xz | Bin 0 -> 234312 bytes
frozen-abi-i686.tar.xz | Bin 0 -> 246472 bytes
frozen-abi-ppc64.tar.xz | Bin 0 -> 242444 bytes
frozen-abi-ppc64le.tar.xz | Bin 0 -> 242624 bytes
frozen-abi-s390x.tar.xz | Bin 0 -> 241872 bytes
frozen-abi-x86_64.tar.xz | Bin 0 -> 240508 bytes
glibc.spec | 183 ++++++++++++++++++++++++++++++++++++++++++++++
8 files changed, 183 insertions(+)
create mode 100644 frozen-abi-aarch64.tar.xz
create mode 100644 frozen-abi-armv7hl.tar.xz
create mode 100644 frozen-abi-i686.tar.xz
create mode 100644 frozen-abi-ppc64.tar.xz
create mode 100644 frozen-abi-ppc64le.tar.xz
create mode 100644 frozen-abi-s390x.tar.xz
create mode 100644 frozen-abi-x86_64.tar.xz
Note: I would like to backport this to F28 if accepted for Rawhide.
--
Cheers,
Carlos.
6 years, 1 month
[PATCH 1/2] Reorganize %install phase.
by Carlos O'Donell
The %install phase is reorganized into 3 distinct phases, the
first phase where files are modified, a second phase where file
lists are generated, and a final phase where files are only
removed based on list information.
This cleanup makes it very clear when we are done installing
files, and therefore creates a place where we can put ABI
instrumentation to compare the resulting ABI before stripping
and debuginfo generation.
---
glibc.spec | 241 ++++++++++++++++++++++++++++++-------------------------------
1 file changed, 120 insertions(+), 121 deletions(-)
--
Cheers,
Carlos.
6 years, 1 month
[PATCH 0/2] Implement strict ABI checking for glibc.
by Carlos O'Donell
Fedora glibc team,
In the "Platform Interface" document [1] I talk about a
distribution in which there is a distinction between what you run
against and what you compile against.
I had originally designed a new sysroot-glibc package which would
be installed by default, and all applications would compile against
that. However, in hindsight this is backwards to what users want.
They key benefit I wanted was a bullet-proof way to avoid ABI
breaks by using tooling. This would also help lower the bar for
less senior developers contributing without the fear they would
break the ABI.
Consensus is that the normal day-to-day compilation against
libraries like glibc should *not* change, and it should remain the
normal process. Only users that want the newer glibc should have to
add things to their build flags to link with a newer glibc. Likewise
the newer glibc should be deployed as either a distinct package
or in a distinct repository with the required packaging changes
(provides all of it's interfaces in a sysroot, and a replacement
runtime). If you are going to use the new glibc for compiling against
then you must also install the new glibc for runtime. That is to say
we support upgrading the development environment, but we do not
support distinct cross-compilation (difficult to do without a lot
of coordination on --prefix=/usr installed runtime data like locales,
caches, etc).
Therefore since I plan to retain a system glibc default installation
that installation could benefit from more robust ABI checking, like
we *would* have had if we compiled against a sysroot for the system
glibc.
The following two patches do just that.
Patch 1/2 cleans up the glibc %install phase.
Patch 2/2 introduces a process to record the ABI for all shared
libraries, and then use that frozen ABI record to verify the ABI
in great detail.
This ABI checking is beyond what glibc does with *.abilist checking,
and closer to what distributions are doing with their package release
process (not yet standardized). Perhaps we will move this upstream
one day when we've had more experience with it in Fedora.
We currently rely on libabigail for ABI serialization.
--
Cheers,
Carlos.
[1] https://fedoraproject.org/wiki/PlatformInterface
6 years, 1 month
