Bug 36298

Система зависимостей не всегда была столь совершенна, как сейчас. Уберу в следующей версии-релизе.

$ rpmquery --provides -p glib2-devel-2.60.0-alt1.x86_64.rpm |grep ^python3
python3(codegen) < 0
python3(codegen) = set:edFi
python3(codegen_docbook) = set:edFi
python3(codegen_main) = set:edFi
python3(config) = set:edFi
python3(dbustypes) = set:edFi
python3(parser) = set:edFi
python3(utils) = set:edFi

[#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm
x86_64: NEW unmet dependencies detected:
libgio-devel#2.60.1-alt1	python3(codegen) < 0
	i586: NEW unmet dependencies detected:
libgio-devel#2.60.1-alt1	python3(codegen) < 0
	aarch64: NEW unmet dependencies detected:
libgio-devel#2.60.1-alt1	python3(codegen) < 0

(In reply to comment #3)
> [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm
> x86_64: NEW unmet dependencies detected:
> libgio-devel#2.60.1-alt1    python3(codegen) < 0
>     i586: NEW unmet dependencies detected:
> libgio-devel#2.60.1-alt1    python3(codegen) < 0
>     aarch64: NEW unmet dependencies detected:
> libgio-devel#2.60.1-alt1    python3(codegen) < 0

Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет.
Если не перекладывать, то нужен какой-нибудь
%add_python3_path /usr/share/glib-2.0

(In reply to comment #4)
> (In reply to comment #3)
> > [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm
> > x86_64: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> >     i586: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> >     aarch64: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> 
> Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет.
> Если не перекладывать, то нужен какой-нибудь
> %add_python3_path /usr/share/glib-2.0

Если известно, что модули будут искаться где-то в нестандартных местах, то это можно сообщить в спеке с помощью

%allow_python3_import_path

(при сборке тех пакетов, которые умеют искать в нестандартном месте).

(В ответ на комментарий №4)
> (In reply to comment #3)
> > [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm
> > x86_64: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> >     i586: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> >     aarch64: NEW unmet dependencies detected:
> > libgio-devel#2.60.1-alt1    python3(codegen) < 0
> 
> Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет.
> Если не перекладывать, то нужен какой-нибудь
> %add_python3_path /usr/share/glib-2.0

Ищет, ищет, -- не находит.
Давно прописано. 
%add_python3_path %_datadir/glib-2.0/codegen

(В ответ на комментарий №5)
> Если известно, что модули будут искаться где-то в нестандартных местах, то это
> можно сообщить в спеке с помощью
> 
> %allow_python3_import_path

%add_python3_path уже недостаточно?

Да, /usr/bin/gdbus-codegen из libgio-devel умеет искать в нестандартном месте. Было бы хорошо указать его с помощью %allow_python3_import_path

$ cat /usr/bin/gdbus-codegen
#!/usr/bin/env python3

# GDBus - GLib D-Bus Library
#
# Copyright (C) 2008-2011 Red Hat, Inc.
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General
# Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
#
# Author: David Zeuthen <davidz@redhat.com>


import os
import sys

srcdir = os.getenv('UNINSTALLED_GLIB_SRCDIR', None)
filedir = os.path.dirname(__file__)

if srcdir is not None:
    path = os.path.join(srcdir, 'gio', 'gdbus-2.0')
elif os.path.basename(filedir) == 'bin':
    # Make the prefix containing gdbus-codegen 'relocatable' at runtime by
    # adding /some/prefix/bin/../share/glib-2.0 to the python path
    path = os.path.join(filedir, '..', 'share', 'glib-2.0')
else:
    # Assume that the modules we need are in the current directory and add the
    # parent directory to the python path.
    path = os.path.join(filedir, '..')

# Canonicalize, then do further testing
path = os.path.abspath(path)

# If the above path detection failed, use the hard-coded datadir. This can
# happen when, for instance, bindir and datadir are not in the same prefix or
# on Windows where we cannot make any guarantees about the directory structure.
#
# In these cases our installation cannot be relocatable, but at least we should
# be able to find the codegen module.
if not os.path.isfile(os.path.join(path, 'codegen', 'codegen_main.py')):
    path = os.path.join('/usr/share', 'glib-2.0')

sys.path.insert(0, path)
from codegen import codegen_main

sys.exit(codegen_main.codegen_main())

(In reply to comment #7)
> (В ответ на комментарий №5)
> > Если известно, что модули будут искаться где-то в нестандартных местах, то это
> > можно сообщить в спеке с помощью
> > 
> > %allow_python3_import_path
> 
> %add_python3_path уже недостаточно?

Да, я когда-то разделил: %add_python3_path повлияет на Provides; на Requires повлияет %allow_python3_import_path

Теперь вот задумался, удачно ли это. Если пакет несёт в себе модули в нестандартном месте, то и использовать он, вероятно, их может. Если же не несёт модули в нестандартном месте, то %add_python3_path всё равно не сможет повредить, кажется. Наверное, можно было бы эти действия объединить в одном макросе. Даже не знаю, почему мне это рассуждение сразу в голову не пришло, могут ли быть какие-то противопоказания.

(В ответ на комментарий №9)
> (In
> могут ли быть какие-то противопоказания.

Нет противопоказаний. Можете  придумать очередной макрос, чтобы запретить провайдить из нестандартных мест, а %add_python3_path вернуть прежнее поведение.

Теперь мне кажется, что можно было бы в %add_python3_path добавить действие %allow_python3_import_path; %allow_python3_import_path для совместимости оставить  таким же или сделать синонимом %add_python3_path

Не уверен, что решусь это сделать, пока собирают python3 сейчас.

(In reply to comment #10)
> (В ответ на комментарий №9)
> > (In
> > могут ли быть какие-то противопоказания.
> 
> Нет противопоказаний. Можете  придумать очередной макрос, чтобы запретить
> провайдить из нестандартных мест,

Думаю, в этом нет особой необходимости, потому что они всё равно эти Provides не сомгут удовлетворить обычные Requires.

(В ответ на комментарий №11)
> Теперь мне кажется, что можно было бы в %add_python3_path добавить действие
> %allow_python3_import_path; %allow_python3_import_path для совместимости
> оставить  таким же или сделать синонимом %add_python3_path

Чудесно, перевешиваю на rpm-build-python3. В glib2 этот %allow прописал.