ALT Linux Bugzilla – #31992

rpm-build-python3-0.1.10

+++ This bug was initially created as a clone of Bug #31948 +++

https://bugzilla.altlinux.org/show_bug.cgi?id=31948#c6

(In reply to comment #4)

> Странность в том, что в одном модуле есть provide, а в другом нет:
> $ rpm -q --provides -p python-module-youtube_dl-2016.04.06-alt1.noarch.rpm |
> grep '(youtube_dl)'
> python2.7(youtube_dl)
> $ rpm -q --provides -p python3-module-youtube_dl-2016.04.06-alt1.noarch.rpm |
> grep '(youtube_dl)'

Понял, почему. Там довольно извращённая логика, особенно в python3.prov.files.
Вот сравните отрывки из начала python.prov.files и python3.prov.files.

python.prov.files:

    case "$t" in
        # skip python3 files
        *"python3 script text"*)
            continue ;;
        # shortcut for real python scripts
        "python script text executable")
            echo "$f"
            continue ;;
        # shortcut for possible python extensions
        *ELF*" shared object"*)

...

            continue ;;
    esac

python3.prov.files:

    case "$t" in
        # skip python2 files
        "python script text executable")
            continue ;;
        # shortcut for real python scripts
        "python3 script text executable")
            echo "$f"
            continue ;;
        # shortcut for possible python extensions
        *ELF*" shared object"*)
            case "$f" in
                ${RPM_BUILD_ROOT-}*/python3*/*.so)
                    echo "$f" ;;
            esac
            continue ;;
    esac

А file говорит на них просто "python script text executable" (версию у него нет
возможности определить) и мы радостно игнорируем его в python3.prov.files.

$ file /usr/lib/python3/site-packages/youtube_dl/*
/usr/lib/python3/site-packages/youtube_dl/YoutubeDL.py:  python script text
executable
/usr/lib/python3/site-packages/youtube_dl/__init__.py:   python script text
executable
/usr/lib/python3/site-packages/youtube_dl/__main__.py:   python script text
executable
/usr/lib/python3/site-packages/youtube_dl/__pycache__:   directory
/usr/lib/python3/site-packages/youtube_dl/aes.py:        ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/cache.py:      ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/compat.py:     ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/downloader:    directory
/usr/lib/python3/site-packages/youtube_dl/extractor:     directory
/usr/lib/python3/site-packages/youtube_dl/jsinterp.py:   ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/options.py:    ASCII Java program
text, with very long lines
/usr/lib/python3/site-packages/youtube_dl/postprocessor: directory
/usr/lib/python3/site-packages/youtube_dl/swfinterp.py:  ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/update.py:     ASCII Java program
text
/usr/lib/python3/site-packages/youtube_dl/utils.py:      python script text
executable
/usr/lib/python3/site-packages/youtube_dl/version.py:    ASCII Java program
text


Я недавно немного поменял похожую штуку в python3.req.files (потому что
недополучение requires меня беспокоило больше -- с точки зрения создания
дистрибутива) -- да и то, только в том, что касалось .so (сделал основным
критерием ответ is_python3_path, о чём сообщал в одном письме в devel).

Переписывать сильнее у меня не было сил.

Но вот в этом месте вроде очевидно, что такой ответ file не должен быть
причиной игнорирования. Может быть, придумаю, как переписать. Или предлагайте
варианты.