[devel] I: NMU to clean up %ubt in spec

[Andrey Savchenko]

On Mon, 17 Jun 2019 23:19:47 +0300 Yuri Sedunov wrote:
> > 
> > И уж лучше закинутые тарболом исходники, чем "pristine sources",
> > в которых при работе приходится вечно переключаться между бранчем со
> > спеком и бранчем с кодом, не забывая при этом обновлять
> > .gear/tags/list при каждой попытке что-то собрать. Спасибо,
> > я наелся этого выше крыши с тем же ruby. Врагу не пожелаю.
> 
> Так, не надо переделывать srpm в git -- мартышкин труд.
> Распаковали srpm (хотя я редко это делаю, поскольку актуальные спеки,
> патчи почти всегда под рукой), на соседних вкладках терминала
> расположили гиты апстримные и какие-другие, если требуются, локальную
> или удаленную сборочечницу и комфортно-быстро пачками, параллельно в
> многозадачном режиме собираете пакеты.

При чём тут srpm? Чукча не читатель, чукча писатель? Мне вот
пришлось работать с git пакетом ruby, сделанным по концепции
"pristine sources" — и не я его создавал, я уже с готовым работал
решая имеющиеся задачи. И в этом готовом пакете в разных бранчах
лежат исходник и обвязка (spec и вспомогательные файлы), притом в
каждом бранче только свои файлы. А для решения задачи мне нужно было
много редактировать и то, и другое. Приходилось постоянно
переключаться между бранчами, потому что в git by design нельзя
отобразить оба бранча сразу. В итоге очень много времени и нервов
было потрачено из-за этого идиотизма.

Я не против ситуации, когда разные бранчи объединяются друг в друга
вместе с объединением файлов — так тот же glibc сделан, с этим
можно нормально работать. Но pristine sources — ужас похуже srpm.

Я сам srpm не очень люблю, т.к. там не сохраняется история. Но в
случаях, когда пакеты без изменений переносятся между разными
сборочницами это оправдано.

Best regards,
Andrew Savchenko
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20190618/000ca40f/attachment.bin>