Created attachment 17077 [details] соберите этот спек чтобы воспроизвести проблему При сборке одного проекта на go наткнулся на интересную проблему: часть сгенерированных исходников эта штука называет something[generated].go, а наш rpmbuild позже воспринимает квадратные скобки как glob. Проще всего реализовать воспроизвести эту проблему с помощью приложенного spec-файла, который на моей системе не собирается со следующей ошибкой: [...] Creating bracket-test-debuginfo package Processing files: bracket-test-debuginfo-0.1-alt1 error: File not found by glob: /tmp/.private/iv/RPM/TMP/bracket-test-buildroot/usr/src/debug/test[generated].c RPM build errors: File not found by glob: /tmp/.private/iv/RPM/TMP/bracket-test-buildroot/usr/src/debug/test[generated].c
> часть сгенерированных исходников эта штука называет something[generated].go Оказывается эти исходники довольно сложно переименовать, наверное придётся отключить debuginfo пока это не исправленно.
Похоже это баг в логике build/files.c:processBinaryFile. Сначала определяется что fileURL это glob, по наличию ? * [ ], если glob, то он обрабатывается как glob (с экранированием символов через \, а если не glob, то обрабатывается как путь (без поддержки экранирования). То есть если добавить экранирование, то путь перестает быть glob и символы экранирования испортят путь. И это должно относиться не только к debuginfo, а к любым файлам.
Я думаю правильным было бы изначально считать тот путь glob'ом. Но, просто отключить это уже нельзя из-за возможных неочевидных последствий. Апстрим поменял логику в c10e2310e4c41a626b524ae71b3c4f87a29134b2, это огромный коммит. [Ссылающийся на коммит 4030062f2bf16d7a4540c78c1e61706f3810fe9b, которого нет (видимо rebase его потер).] Другой вариант - придумать что-то ALT-specific.
> Другой вариант - придумать что-то ALT-specific. RFC https://git.altlinux.org/tasks/361121/
(In reply to Vitaly Chikunov from comment #4) > RFC https://git.altlinux.org/tasks/361121/ В теории, наверное, было бы ещё удобнее если бы это делалось через %attr или что-то такое, чтобы можно было glob выключить и потом включить обратно. Но пока что это, вроде, не нужно. LGTM
(In reply to Vitaly Chikunov from comment #4) > > Другой вариант - придумать что-то ALT-specific. > RFC https://git.altlinux.org/tasks/361121/ Вдогонку: есть ли у нас (стоит ли добавить) тест, покрывающий файлы с пробелами — записи в %files, видимо, такого вида: %files --noglob "%_datadir/project/2001 a space odyssey" "%_datadir/project/2001[a space odyssey]" ? А то rpm-s-m, исправляя у себя, столкнулись с поломкой таких файлов.
(In reply to Vitaly Chikunov from comment #4) > > Другой вариант - придумать что-то ALT-specific. > > RFC https://git.altlinux.org/tasks/361121/ Для генератных пакетов — LGTM, за исключением соображения выше. (In reply to Gleb F-Malinovskiy from comment #5) > (In reply to Vitaly Chikunov from comment #4) > > RFC https://git.altlinux.org/tasks/361121/ > > В теории, наверное, было бы ещё удобнее если бы это делалось через %attr или > что-то такое, чтобы можно было glob выключить и потом включить обратно. Но > пока что это, вроде, не нужно. Когда секцию пишет человек — да. А роботу-генератору, как я imho себе их представляю, так будет менее удобно: у него получился список готовых путей, и ему нужно их в неизменном виде донести до rpm-build.
(In reply to Vitaly Chikunov from comment #2) > Похоже это баг в логике build/files.c:processBinaryFile. Сначала > определяется что fileURL это glob, по наличию ? * [ ], если glob, то он > обрабатывается как glob (с экранированием символов через \, а если не glob, > то обрабатывается как путь (без поддержки экранирования). То есть если > добавить экранирование, то путь перестает быть glob и символы экранирования > испортят путь. Кстати, в этом случае в качестве объезда можно сделать, чтобы это всегда был glob, а сам путь при этом остался однозначным. Я вспомнил, что мы делаем похожее в сборочнице с git-ом, там вот такое есть: old_tag_id="$(git rev-parse --tags="[${tag_name:0:1}]${tag_name:1}")"
