Hi, Ranjan Maitra via users wrote: > I have a program called gbuffy which is very old, but used to compile fine in > F41 (and even in F42). > > I am able to create a RPM but I have a strange problem in that while > installing it, I get: > > $ sudo dnf install ../RPMS/x86_64/gbuffy-0.2.8-3.fc42.x86_64.rpm > Updating and loading repositories: > Repositories loaded. > Failed to resolve the transaction: > Problem: conflicting requests > - nothing provides libcrypto.so.1.1()(64bit) needed by > gbuffy-0.2.8-3.fc42.x86_64 from @commandline > - nothing provides libssl.so.1.1()(64bit) needed by > gbuffy-0.2.8-3.fc42.x86_64 from @commandline > - nothing provides libssl.so.1.1(OPENSSL_1_1_0)(64bit) needed by > gbuffy-0.2.8-3.fc42.x86_64 from @commandline > You can try to add to command line: > --skip-broken to skip uninstallable packages > > I do not understand what the issue is. The spec file explicitly disables > openssl and does not even require it.
The build section of the spec file you pasted contains:
%build
./configure --with-ssl=no --disable-ssl
%configure
%make_build
It's calling %configure again, which overwrites the build
options you passed to the manual ./configure call on the
previous line.
Without seeing the configure script, it's hard to know
whether you really want or need both the --with-ssl=no and
--disable-ssl. That _seems_ rather unusual.
If they are both needed (./configure --help might help, or
reading the configure.(ac|in) file should clarify that), I'd
move those to the %configure line and drop the direct call
to ./configure, That's what the %configure macro does, after
all.
%build
%configure --with-ssl=no --disable-ssl
%make_build
You can use `rpm -E %configure` to see the fully expanded
macro, BTW.
> The RPM requires libPropList but that RPM (mine) installs
> without error.
If you look through the build output carefully, you should
notice configure being run twice and, I suspect, the second
enables ssl. It may show what it linked against (which, I
guess, is a locally installed openssl1<something>).
I see libPropList is listed as a BuildRequires. Is it
needed at build or install time? Typically, I'd expect the
BuildRequires to be more like: libPropList-devel to get the
necessary headers and such to build against.
> Btw, here is the spec file:
> https://paste.centos.org/view/0e22b18d
>
> However, I am not sure where to put the bz2 or the
> libPropList RPM, so the spec file can not be compiled
> without these.
I see the Source0 file you have specified as an absolute
path. That suggests that you're building this directly on
your host system as opposed to using an isolated build
environment like mock provides. While you can do that, it
is likely to hide other missing BuildRequires from you,
which might cause you problems if you build a new system and
trying to build this rpm again.
So, only a little tangentially, I'd suggest using mock to
build the rpm to help ensure you're not missing other
BuildRequires. That also helps make sure that running
./configure doesn't find older openssl 1.1 headers/libraries
on your system.
As far as where to put Source0 and the libPropList rpm,
Source0 is ideally placed in the location specified by the
%{_sourcedir} macro. On current Fedora/rpm releases, that
is: ~/rpmbuild/SOURCES. Similarly, the spec file, by
default, would go in ~/rpmbuild/SPECS. Installing the
rpmdevtools package and running rpmdev-setuptree will create
the ~/rpmbuild directory and its various children, if you
don't already have it.
Then you can simply specify it as:
Source0: %{name}-%{version}.tar.bz2
in your spec file.
For the libPropList rpm (and your eventual gbuffy package),
placing them in a directory and using createrepo is a
relatively simple way to get a local repository. That can
be served over https:// or some other network protocols, but
it's also trivial to use on the local host.
Let's say you put your packages in ~/repo/fedora/41/x86_64.
You would create a yum repo file in /etc/yum.repos.d/, maybe
called ranjan.repo:
cat <<-EOF >/etc/yum.repos.d/ranjan.repo
[ranjan]
name=Ranjan's Packages for Fedora $releasever - $basearch
baseurl=file:///home/ranjan/repo/fedora/$releasever/$basearch
enabled=1
# a next step is to sign the packages and let dnf verify
# them
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ranjan
gpgcheck=0
metadata_expire=60
EOF
Then you move the rpms you have into the repo directory and
run `createrepo ~/repo/fedora/41/x86_64` to generate the
repodata directory and files which dnf will read. Then you
can install package from your local repo just like you do
from any other.
That can be integrated with mock as well, should you get to
the point where you are using it to build your packages
instead of doing it directly on your host system.
In /etc/mock/fedora-41-x86_64-ranjan.cfg, you'd put this,
which just includes the main fedora-41 mock config and a
template for your local repo:
include('fedora-41-x86_64.cfg')
include('templates/ranjan.tpl')
And in /etc/mock/templates/ranjan.tpl, you'd have what is
essentially a copy of your repo config:
config_opts['dnf.conf'] += """
[ranjan]
name=ranjan
baseurl=file:///home/ranjan/repo/fedora/{{ releasever }}/{{ target_arch }}
gpgcheck=0
"""
Using mock is some extra work initially, but it does save a
lot of hassle over time. It ensures you're building
packages which have the requisite BuildRequires as opposed
to maybe missing some which you happened to have installed
on your main system. And it allows you to not install all
of those devel packages on your host in the first place.
You can also build for different version of Fedora, RHEL
(and Rocky or Alma) as well as a number of other RPM-based
distributions.
--
Todd
signature.asc
Description: PGP signature
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
