Hi,
https://bugzilla.redhat.com/show_bug.cgi?id=1249325
GDB requires some library libXXX.so.3 by dlopen(). Therefore it is not found
by rpm automatic requires/provides from DT_NEEDED. Therefore one has to add
the libXXX.so.3 by specific BuildRequires and Requires to the .spec file.
libXXX is librpm here but that is just a coincidence, it could be libz for
example.
(1) How to make a dependency on librpm.so.7?
librpm.so.7 is in rpm-libs-4.12.90-3.fc24.x86_64 which --provides:
librpm.so.7()(64bit)
librpmio.so.7()(64bit)
rpm-libs = 4.12.90-3.fc24
rpm-libs(x86-64) = 4.12.90-3.fc24
So there is no easy way to Requires: rpm-libs = NVRA
I do not see which V introduced / deprecates .so library version 7.
So I would like to: Requires: librpm.so.7
But that does not work as I need there the '()(64bit)' suffix.
%{?_isa} suffix does not work, that is '(x86-64)' and not '()(64bit)'.
I could %ifarch explicitly all 64-bit Fedora archs to append '()(64bit)' for
them but isn't there some better way how to generate the '()(64bit)' suffix?
(2) The other possibility does work:
BuildRequires: %{_libdir}/librpm.so.7
But
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
says
Whenever possible you should avoid file dependencies as they slow down
dependency resolution and require the package manager to download file
lists in addition to to regular dependency information.
>From what I remember at least yum did not need the 'filelists' index for
/usr/bin/ files. Is it still valid today and also for dnf?
And is 'filelists' required for /usr/lib{,64}/ or not?
I think Packaging Guidelines could list these few directories - at least
/usr/bin/ - for safe file dependencies.
Thanks,
Jan

= Proposed System Wide Change: Python 3.5 =
https://fedoraproject.org/wiki/Changes/python3.5
Change owner(s):
* Robert Kuska <rkuska at redhat dot com>
* Matej Stuchlik <mstuchli at redhat dot com>
Update the Python 3 stack in Fedora from Python 3.4 to Python 3.5.
== Detailed Description ==
Python 3.5 adds numerous features and optimizations. See the upstream
notes at What's new in 3.5.
== Scope ==
As Python3.5 was already released as a final release and Debian had
already updated their Python to v3.5 we could expect all the core
(most used) Python modules to be already Python3.5 compatible.
There is 973 packages that (Build)Requires python3 (in F24). Also it
is important to note that Python3 is now the default interpreter for
Fedora therefore it is crucial part of the distribution (anaconda and
dnf run on Python).
* Proposal owners:
** Make a request to create a f24-python3 side-tag for Python3.5 rebuild.
** Rebuild gdb without python3 support to have minimal buildroot
python3 free as we can't have (currently) simultaneously installed
both Python3.4 and Python3.5 versions within the buildroot.
** Build Python3.5.
** Rebuild gdb and all the packages marked as core within this tag. We
consider all packages shipped by default (and their dependencies) on
Fedora DVD to be core packages.
** Rebuild rest of the packages in mass rebuild
* Other developers:
Owners of packages that fail to rebuild will be asked using bugzilla
to fix or remove their packages from the distribution. They can
rebuild their packages themselves if interested using fedpkg build
--target f24-python3. We will keep the list of rebuilt
packages/packages in queue publicly accessible.
* Release engineering:
Mass rebuild rest of the packages.
* Policies and guidelines:
None
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Hi all,
This may have been an insane proposition, so I'm asking here before I go
near bugzilla.
I installed a clean F23 beta machine, then used dnf system upgrade to
try and move up to Rawhide.
When I rebooted the system, I got the 'Oh no! Something has gone wrong'
screen, which repeats if I try and relaunch GDM.
The only relevant error in the journal is:
Glib: g_hash_table_find: assertion 'version == hash_table->version'
failed
Setting 'setenforce 0', or setting selinux to permissive in the config
allows everything to work normally.
I have tried relabelling the filesystem.
Is this an insane unsupportable upgrade path or could I have found an
actual bug?
--
Richard Bradfield