[RFC] %configure macro when missing a ./configure script
by Japheth Cleaver
I seem to recall discussion on this in the ancient past, but I couldn't
find anything in the archive, nor on the current Fedora Packaging
Guidelines docs.
There exist upstreams out there that are written in C/C++ but don't ship
with a "configure" script. In some cases, I've seen this addressed by
simply not running the %configure macro and then make-ing as normal, or
by manually using %optflags somewhere. This is the suggestion in some
tutorials for addressing this, e.g.:
https://rpm-packaging-guide.github.io/#cello-working-with-spec-files
The %build section is where we tell the system how to actually build
the software we are packaging. Since wrote a simple Makefile for our
C implementation, we can simply use the GNU make command provided by
rpmdev-newspec. However, we need to remove the call to %configure
because we did not provide a configure script
I'd like to propose the addition of a "Configuration" section in the FPG
(probably right under
https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler )
that addresses the importance of using %configure. It ensures flags are
properly exported into the environment, but could also do other
arbitrary, distro-dependent things at some point, so it's still better
to run the macro than not. There are two possible workarounds, depending
on the whether %_configure (with underscore) is available, or if more
control is needed for simulating a script.
Safer:
%build
# source has no configure script; use macro anyway
echo "#!/bin/sh" > configure ; chmod +x configure
%configure
make %{?_smp_mflags}
Recent versions; simple case:
%build
# source has no configure script; use macro anyway
%define _configure /bin/true
%configure
make %{?_smp_mflags}
I submitted
https://github.com/redhat-developer/rpm-packaging-guide/issues/75 for
that doc, but it seems like something about whether/how to work around
this should be in these guidelines too, since they're used so much as a
general reference.
Regards,
-jc
3 years, 9 months
RFC: systemize packaging that manipulates implicit XML catalog
by Jan Pokorný
Hello,
it was brought to my attention that unlike in Fedora, openSUSE has
taken care of the (relatively niche) area of dealing with packages'
entries to what other SW consumes (directly or via transitive chain
of catalogs) from /etc/xml/catalog file:
https://en.opensuse.org/openSUSE:Packaging_XML_Schemas_and_Stylesheets
What follows is a natural consideration whether it would, for once,
make sense for Fedora to follow this example, for ~3 reasons:
0. less imperative, more declarative is issually somewhat more
relaxed at both "produce" and "grok" directions
1. it's easy to forget about the removal part when using explicit
procedural form of registering a custom catalog in pre/post
scriptlets (it happened to me with upstream, thanks to the reviewer
for spotting it, and actually also for pointing the openSUSE
advancement in this packaging territory per above)
2. unified path for the custom catalogs to allow for immediately
groking the delegations without even reviewing /etc/xml/catalog
file in detail
3. sticking with what openSUSE already does means less of a wide
RPM ecosystem fragmentation
Now, if this received a positive feedback, I am not sure how to
go about rewriting update-xml-catalog executable from scratch
vs. just adopting theirs, regarding proper license compatibility,
attributions, in which package to put it, etc. But I guess,
that'd be secondary, so what I want to know at this point is
whether:
- such a packaging related "enablement" would make sense,
with an outlook to eventually (given the proper Fedora
change process if eligible here) mandate the use of this
new mechanism for hooking custom XML catalogs in,
perhaps to the extent that /etc/xml/catalog would be
assumed immutable, with only the pre-delegated catalog
eligible for changes
- there is a precedent of Fedora adopting parts of openSUSE
packaging practices, like it would be the case here
Thanks
--
Jan (Poki)
3 years, 9 months
libfoo.$major requirements/guidelines
by Brian J. Murrell
I've been unable to locate any packaging guidelines/requirements that indicate that a source package providing shared libraries should have those shared libraries packaged into a sub-package with the major version of library appended to the sub-package name (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent installation of the differing major versions of the library.
Is there no such guideline/requirement?
3 years, 9 months
Policy regarding packages modifying firewall rules
by Christopher Engelhard
Hi,
what is the policy regarding software that requires modifications to the
firewall in order to run?
Specifically, I'm packaging sshguard (a brute-force blocking software
similar to fail2ban, I've asked about it here before [1]), which
maintains a list of blocked ips/subnets in ipsets. When using firewalld
and nftables, these ipsets are created automatically when the program
first runs, but for iptables the user has to set them up beforehand.
- should the (iptables sub-)package set these up during first install
instead? If not, should the user be notified of the required steps in
e.g. a scriptlet?
- for all backends, should the ipsets be removed when the package is
uninstalled?
I think similar arguments as for user creation/deletions apply, so would
go for create-automatically-and-never-delete, but maybe there already is
an existing policy on this? I had a look at the fail2ban spec, but
fail2ban seems to take care of firewall configuration entirely on its own.
Best,
Christopher
[1]
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
3 years, 9 months
