I just submitted my first review request on Bugzilla :
https://bugzilla.redhat.com/show_bug.cgi?id=1706548. The packaged
software is called "simple-dnf" and it is meant to be a lightweight (and
fast) GUI for DNF. I did not create it but I found it very quite cool
and effective; as I was interested by the packaging world I decided to
create a COPR repository for testing purpose:
https://copr.fedorainfracloud.org/coprs/arkelis/simple-dnf/, now I'm
submitting for official repo!
To introduce myself, I'm Guillaume Fayard, a French student at a general
engineering school; I'm interested in Python, Web development, Server
administration... I did not yet contribute to many open source project,
I usually help to translate things (for example Python docs). I have
small website (in French) hosting various documents I'm writing / I
I need to install a directory (/afs) that will be a mountpoint that a systemd
service (also installed in the rpm) will mount upon.
What's the best way to encode this in the specfile?
I did have:
but that doesn't upgrade correctly. Someone gave me another way to do it:
# Create /afs directory if it doesn't exist
if [ ! -d /afs ]; then
chown root.root /afs
chmod 0755 /afs
[ -x /usr/sbin/restorecon ] && /usr/sbin/restorecon /afs
%ghost %dir /afs
but rpmlint complains about the chown:
kafs-client.x86_64: W: dangerous-command-in-%post chown
The git repo is here:
The second patch from the top is the one that tries to fix the mountpoint dir
installation issue ("spec: Treat /afs special").
For some reason, a "mock install" ends up running %post scripts with
LC_ALL=en_US.UTF8, for which I need glibc-all-langpacks.
This does not happen with a manual install from a mock shell.
The tiny spec file below reproduces the problem.
If I use "mock -n install" (I have a few other things in the chroot that I
need), the log file shows that the locale is en_US.UTF8.
If I run a mock shell, and manully "rpm -i" inside the shell, the locale is
the expected C.UTF-8
Anyone knows why I'm getting a bad locale, with mock install?
Summary: Locale in mock
Group: System Environment/Base
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT
rm -rf $RPM_BUILD_ROOT
* Mon May 6 2019 Sam Varshavchik <mrsam(a)octopus.email-scan.com> -
- Initial build.
currently, we autogenerate a dependency on pkg-config for all rpms
that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config"
returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something
that is used by pkg-config, they don't *require* pkg-config for anything.
As an analogy, packages with headers are read by a C compiler, but
we don't make them require gcc, and if a package ships an .so file, we
don't add a dependency on the linker to it. Instead, anything which wants
to consume .pc files should simply depend on the tools that consume those
files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config
(this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not
part of this proposal.
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf)
(Those packages are small, maybe 200k together so this isn't a strong
- stuff that uses pkg-config or pkgconf will need to grow a dependency
(e.g. meson which invokes /usr/bin/pkg-config internally).
so there will be some churn.