The packaging guidelines currently allow file dependencies in /etc,
/usr/bin, and /usr/sbin to be used in spec files. However, this can
pose a problem for Fedora Flatpak builds, where an ever-growing number
of packages are being built for flatpaks in /app which breaks such file
dependencies.
(A separate problem is posed by the use of installation path macros in
file dependencies, but that is already disallowed; see further
discussion in https://pagure.io/packaging-committee/pull-request/1346 )
Regarding /usr/bin and /usr/sbin file dependencies, generally the
intention is "require whichever package that installs this command in
$PATH". In such a case, it doesn't really matter if it's in /usr/bin
(for normal RPM builds, or for packages in the flatpak runtime, or for
flatpak buildroot-only dependencies) or in /app/bin (from packages
built for flatpaks). While the package name providing that command
could be used, package contents can vary over time, and maintainers
want to avoid having to track that.
Common examples are /usr/bin/groff (groff-base) and /usr/bin/pod2man
(perl-podlators), both of which are now built in /app to support perl
for flatpak apps.
Option 1 would be for either rpm or redhat-rpm-config to generate e.g.
cmd(foo) virtual provides for /usr/bin/foo or /usr/sbin/foo (and for
flatpaks, also for /app/bin/foo or /app/sbin/foo). Packages would then
[B]R: cmd(foo), and (eventually) file dependencies in /usr could be
dropped entirely. (The "cmd" name is just an example and could of
course be changed.)
The major disadvantage of this approach is the implementation time
involved. Even if it were to be implemented prior to the F41 mass
rebuild, it would not be usable across all stable Fedora versions until
the middle of F43 development (after F40 EOL), and wouldn't be
compatible with EPEL for a long time (although that could be shortened
somewhat if it gets into c10s before the last mass rebuild). It would
also create a lot more virtual provides, but would be a big step closer
to dropping file dependencies entirely.
Option 2 would be to boolean dependencies, e.g.:
[Build]Requires: (/usr/bin/foo or /app/bin/foo)
This would avoid the implementation delay but is much more verbose.
Thoughts?
--
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
Hello boys, girls and what nots,
I'm an old fart that used to maintain 1/3 of the Mandriva Linux
distribution back in the day, and other stuff. That was pretty wild!
I've been lurking around here in the background for some years trying to
find something useful to do and to contribute with. I tried with
maxscale in 2016 but that failed due to a license change. I thought it
would be great to break out libinjection from mod_security but then I
realized it's pretty much dead.
So, now I found laurel that is not packaged yet (besides debian?). My
first ever rust package :-)
My status as an active fedora maintainer surely must have expired by now
but maybe I can get a sponsor to help me activate this again and get me
going?.
Anyways, the laurel stuff is here: https://repo.nux.se/laurel/
It builds on FC40 and RHEL 9, probably for RHEL 8 as well but I haven't
tried that yet. I have probably made a lot of mistakes in the spec file,
but consider it as a first take.
I really hope laurel is not needed and it's just a matter of cooking up
some some voodoo magic sauce to make it work in your SIEM platform.
Please enlighten me if that's the case.
Happy midsummer eve!
--
Regards // The penguin whisperer
Hi,
I was fixing a FTBFS https://bugzilla.redhat.com/show_bug.cgi?id=2291622
in the package python-astroquery
The reason of the failure were two files, installed but unpackaged,
both in python3_sitelib named:
astroquery/ipac/irsa/tests/data/.#.MOST_full_with_tarballs.html.tmp
astroquery/ipac/irsa/tests/data/.#.MOST_regular.html.tmp
These two files are not in the tarball and I have checked that they
appear after %install and before %check
The package has files named MOST_full_with_tarballs.html and
MOST_regular.html in the same folder as well as other files that seem
unaffected.
The same package builds in fedora 40 without problems.
Any idea of what is happening?
Regards, Sergio
I'm performing a package review [1] for which I get some rpmlint errors and warnings, but I'm unsure how to proceed...
> > - rpmlint errors
> > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
> > /usr/lib64/libsolsys2.so.1.0.1 jplint_ (/usr/lib64/libsolsys2.so.1.0.1)
> > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
> > /usr/lib64/libsolsys2.so.1.0.1 jplihp_ (/usr/lib64/libsolsys2.so.1.0.1)
>
> However, the missing `jplint_` and `jplihp_` are an intended feature of the
> `solsys2` plugin. As the description of this sub-package implies this plugin
> requires user-supplied code to work, and these functions are exactly the
> ones that must be defined by the user when using the `libsolsys2` plugin
> library. This whole subpackages is aimed for supporting legacy code only,
> for people who have existing code that define those `jplint_` and `jplihp_`
> symbols, and want to compile their code with supernovas. I can think of 3
> ways to address this:
>
> 1. Let it be as such, if that's OK. (The Debian package has passed the
> initial reviews and is moving to testing with the same setup.)
> 2. I can define weak dummy implementations of the `jplint_` and `jplihp`
> symbols that simply return an error. That would cure the rpmlint errors, but
> it would also hide the fact that the `solsys2` plugin really requires these
> symbols be defined by the user-code. This would probably also mean that I'd
> have to create a new upstream branch/tag (e.g. 1.0.1-3) to distinguish it
> from the one used by the Debian package.
> 3. Drop providing the `solsys2` plugin as a library altogether, and supply
> the source code as documentation (examples) only. This is fine, but it
> requires a bit of extra work for people who want to link their existing
> (old) code with the `solsys2` functionality.
>
> What would be your solution?
I suppose we can ignore those errors, as they are just expected?
> > - rpmlint warning
> > supernovas-cio-data.x86_64: W: only-non-binary-in-usr-lib
> > Is the cio_ra.bin an executable? Or it's just a resource? If the latter,
> > maybe it can be moved under %{_datadir}/%{name}?
>
> It is a resource but it is a platform-dependent one -- so it has an 'arch'
> dependence. %{_datadir} has no arch-dependence, but %{_libdir} does, which
> is why I thought this resource might fit there best. Or do you think it's
> better to put arch-dependent data into {%_datadir}, perhaps under a
> %{name}/%{_isa} directory instead?
I'm not sure here: is it expected that {%_datadir} should not contain arch dependent code? Where it is best to provide such resources?
Thanks
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2283055