Если в этой цепочке есть исходники и мейнтейнер, то возможно ему будет удобнее самому это сделать, да. Задача разработчика только исходники подготовить так чтобы было не больно их либо распихать по /etc, /usr/bin, ... в крайнем случае сложить в /opt, но из пакета. Но в любом случае, когда есть "исходники пакета"(например .spec для rpm) мейнтейнеру будет сильно проще понять дивный внутренний мир программы, которую он упаковывает.

Ну вот, мейнтейнер конкретного дистрибутива лучше знает, как положить в пакет - до этого места мы дошли. Тут вы согласны, да? Тогда нафига софтописателю упаковывать в пакет? Чтобы мейнтейнер сначала распаковал, а потом упаковал правильно?

Собственно, чем так принципиально отличается распаковать-из-пакета и распаковать-из-архива?

Ну вот, мейнтейнер конкретного дистрибутива лучше знает, как положить в пакет - до этого места мы дошли. Тут вы согласны, да? Тогда нафига софтописателю упаковывать в пакет? Чтобы мейнтейнер сначала распаковал, а потом упаковал правильно?

Тут немного разные случаи. Я имел в виду, что если софт невозможно упаковать силами мейнтейнера(в силу того что он проприетарный или лицензия не позволяет) то этим лучше заняться разработчикам, предоставив удобную возможность его установить

Под сообществом я имел в виду пользователей

Пользователям срать, они купили программу и хотят, чтобы она работала.

Упаковать вместе с программой в один пакет

В какой конкретно пакет упаковывать?

Собственно, чем так принципиально отличается распаковать-из-пакета и распаковать-из-архива?

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

Тут немного разные случаи. Я имел в виду, что если софт невозможно упаковать силами мейнтейнера(в силу того что он проприетарный или лицензия не позволяет) то этим лучше заняться разработчикам, предоставив удобную возможность его установить

Глупости какие. Если софт можно разложить в системе, и он заработает, то упаковать силами мейнтейнера его точно можно.

В какой конкретно пакет упаковывать?

Ну вот есть какой-нибудь инструмент X, который упаковывается в одноимённый пакет. Он требует зависимость Y, которая не может быть принята в апстрим по каким-то причинам. Тут два варианта: Первый - мы кладём зависимость Y внутрь пакета X таким образом чтобы пакет инкапсулировал её в себе. Второй - создаём пакет Y и прописываем его зависимостью для пакета X. Второй вариант может быть не возможен, если мы хотим отправить пакет в апстрим, либо в виду каких-то особенностей технологии, на которой написана программа X, так что возможно придётся прибегнуть к первому варианту.

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

Не, для чего конкретно нужны пакетные менеджеры, я знаю. Но из ваших хотелок: 1. Надо удалить софтину из /opt - потри каталог /opt/softname 2. История? Зачем она конечному пользователю? Обновление все равно будет ручным. 3. Нужны контрольные суммы - их тоже можно проверить без пакетного менеджера. 4. Перенакактить - удали и распакуй заново.

Глупости какие. Если софт можно разложить в системе, и он заработает, то упаковать силами мейнтейнера его точно можно.

Можно, но иногда лицензия не позволяет. Тойже кафки в репозиториях федоры нет

Не, для чего конкретно нужны пакетные менеджеры, я знаю. Но из ваших хотелок: 1. Надо удалить софтину из /opt - потри каталог /opt/softname 2. История? Зачем она конечному пользователю? Обновление все равно будет ручным. 3. Нужны контрольные суммы - их тоже можно проверить без пакетного менеджера. 4. Перенакактить - удали и распакуй заново.

Не хочу руками трогать ничего, у меня есть пакетный менеджер

Так можно вообще от пакетного менеджера отказаться, зачем, ведь можно всё тарниками накатывать

Ну вот есть какой-нибудь инструмент X, который упаковывается в одноимённый пакет. Он требует зависимость Y, которая не может быть принята в апстрим по каким-то причинам. Тут два варианта: Первый - мы кладём зависимость Y внутрь пакета X таким образом чтобы пакет инкапсулировал её в себе. Второй - создаём пакет Y и прописываем его зависимостью для пакета X. Второй вариант может быть не возможен, если мы хотим отправить пакет в апстрим, либо в виду каких-то особенностей технологии, на которой написана программа X, так что возможно придётся прибегнуть к первому варианту.

Вот место про положить библиотеку /usr/lib/lib_some_shit.15.so с моими патчами так, чтобы она не конфликтовала с системной /usr/lib/libs_some_shit.15.so без моего патча, пожалуйста поподробнее. Как это инкапсулировать в пакет?

Не хочу руками трогать ничего, у меня есть пакетный менеджер

Не ставь сторонний софт. Нет софта - нет проблемы.

Так можно вообще от пакетного менеджера отказаться, зачем, ведь можно всё тарниками накатывать

В теории, в некоторых случаях можно и отказаться, хотя к этому я и не призывал. Просто для разработчика небольшой проприетарной софтины, приносящей ему 200 долларов в месяц, например, я не вижу смысла с опакечиванием.

Вот место про положить библиотеку /usr/lib/lib_some_shit.15.so с моими патчами так, чтобы она не конфликтовала с системной /usr/lib/libs_some_shit.15.so без моего патча, пожалуйста поподробнее. Как это инкапсулировать в пакет?

Унести её в отдельный prefix и загрузить используя LD_PRELOAD. Либо собрать .so с другим path/именем и слинковать свой софт с учетом этого изменения

Унести её в отдельный prefix и загрузить используя LD_PRELOAD. Либо собрать .so с другим path/именем и слинковать свой софт с учетом этого изменения

вот! Вот /opt/vendorname - это и есть конкретно отдельный префикс...

В теории, в некоторых случаях можно и отказаться, хотя к этому я и не призывал. Просто для разработчика небольшой проприетарной софтины, приносящей ему 200 долларов в месяц, например, я не вижу смысла с опакечиванием.

А я вижу. Таких как я не много, но я бы его софтиной не стал пользоваться просто потому что пакета нет, альтернативы поискал бы

итак, вернемся к вопросу, чем вас, собственно, /opt не устраивает

коллеги, ну уймитесь уже, а?

вот! Вот /opt/vendorname - это и есть конкретно отдельный префикс...

Да, только ставится не из пакета :)

В общем, каждый остался при своём :) Но мне стала более ясна польза от /opt именно с точки зрения "выживания в диком мире". Сам я конечно писать софт так, чтобы его было сложно упаковать не собираюсь, но может быть буду чуть меньше ненавидеть разработчиков, которые не закладывают в разработку своих инструментов тот факт что кто-то захочет их опакетить

А я вижу. Таких как я не много, но я бы его софтиной не стал пользоваться просто потому что пакета нет, альтернативы поискал бы

вот из-за таких, как вы, доля линукса на десктопе до 2% добраться не может

кой толк это в публичном месте обсуждать?

коллеги, ну уймитесь уже, а?

Ок, унимаюсь

Предлагаю это обсуждение унести в личку.

Смысла нет)) Не договоримся :D

да хоть чатик отдельный можно создать, и ссылку сюда

кому интересно - придет туда слушать

О, кстати, это мысль

но ведь и правда - не договоритесь

Сорь, разговорились. Пис, люди, пис!

Оо

какая разница между fmt.Errorf и fmt.Printf?

радикальная

какая разница между fmt.Errorf и fmt.Printf?

fmt.Errorf возвращает ошибку, Printf выводит строку на экран.

да хоть чатик отдельный можно создать, и ссылку сюда

Так уже есть: https://t.me/ru_devops

нужно ли пользоваться godep?

сегодня надо пользоваться dep уже

https://github.com/golang/dep

Ух, шустрые какие. Уже ready for production, но changing rapidly, хммм... посижу ка я ещё на glide :)

glide - больше, чем dep. но dep в ближайшее время станет официальной тулзой

glide - больше, чем dep. но dep в ближайшее время станет официальной тулзой

Это кто такое сказал? Сами разработчики явно говорят, что не факт, что dep станет офф тулзой.

https://github.com/golang/dep/wiki/Roadmap

Please remember that finishing these issues does not guarantee dep will be accepted. No external code of this size or significance has ever been pulled into the Go toolchain before, so everyone's kind of playing it by ear.

"Помните, что завершение этих задач не гарантирует принятие dep в тулчейн. Ни один проект до сих пор сопоставимого размера и значения не был принят в Go toolchain. Поэтому поживем, увидим"

https://github.com/golang/go/wiki/PackageManagementTools#dep-tool

dep, will be the official dependency tool.

А кто-нибудь из разработчиков go dep принимает решения о включении в Go toolchain?

есть yaml файл в проекте. как сделать, чтобы при компиляции в бинарник go это учитывал?

https://github.com/jteeuwen/go-bindata

Если я правильно понял

https://dave.cheney.net/2017/07/22/should-go-2-0-support-generics

https://superstas.github.io/io_interfaces.html

Коллеги, есть такая задача: 1. Читать select из базы 2. Считать дифф с тем что в памяти (от прошлых селектов) 3. Маршалить дифф в json Вроде как правильно делать это через структуры, но уж очень неудобно и сравнивать, и тем более чистый дифф слать: настроить пропуск пустых полей можно, но тогда удаленные ключи не отправятся. При этом sqlx в слайс мапов читать не желает, только в слайс структур Как правильно поступить? Вижу два варианта: 1. Читать в struct, тут же конвертить его в map. Тогда и сравнение структур тривиально, по ключам, и дифф легко оформить 2. Читать и хранить struct, дифф через рефлексию формирует map, который все так же легко отмаршалить Первый вариант проще, второй кажется более верным идеологически, что скажете?

Комрадс вопрос. Нужна библиотека, которая позволит для своих тестов, за 5 мин реализовать отображение объектов в 3д. Объекты лайтовые, шарики к примеру или кубики

Просто не хочу сейчас мучаться с освоением какого то двига пару дней. Хочется протестить кое какие алгоритмы.

Комрадс вопрос. Нужна библиотека, которая позволит для своих тестов, за 5 мин реализовать отображение объектов в 3д. Объекты лайтовые, шарики к примеру или кубики

Зачем это делать на Go?

Чисто для практики языка. А вообще, действительно подумываю просто сделать на UE4 c++

Для практики на нём лучше http-вые апишечки делать? 3д - это совсем не то, чем на го обычно занимаются. Но мне просто любопытно стало, либ не подскажу :(

хех. http не интересно на данный момент...

Но в идеале. Хочу поизвращаться и правда сделать 3д на го)

Просто ради процесса так сказать)

Ну вот 3d-over-http

Вообще, по телнету в ascii графике можно сделать.

хы, буду смотреть)

спс)

Коллеги, есть такая задача: 1. Читать select из базы 2. Считать дифф с тем что в памяти (от прошлых селектов) 3. Маршалить дифф в json Вроде как правильно делать это через структуры, но уж очень неудобно и сравнивать, и тем более чистый дифф слать: настроить пропуск пустых полей можно, но тогда удаленные ключи не отправятся. При этом sqlx в слайс мапов читать не желает, только в слайс структур Как правильно поступить? Вижу два варианта: 1. Читать в struct, тут же конвертить его в map. Тогда и сравнение структур тривиально, по ключам, и дифф легко оформить 2. Читать и хранить struct, дифф через рефлексию формирует map, который все так же легко отмаршалить Первый вариант проще, второй кажется более верным идеологически, что скажете?

читай в map[string]interface{}

спс)

SDL2 но сомневаюсь насчет 5 минут! Оконнные приложения OpenGL

Справимся, что уж там)

ну ... все так говорят ... ?

на плюсах же писал граф прилоги

мотивация ... должна быть! НА плюсах чуть проще , в GO дебагер с ума сойдет .... и делать придется "на опыте" ,так что приготовься .... к "слепому" программированию!

я на плюсах не юзал дебагер первые года полора)

полтора*

вернее отладчик

ну ты понял)

Слушай... актуальные два вопроса.

Ты откуда?

географически?

Угу

хех

Второй вопрос уже не так актуален)

есть ли еще 1 балахон такой)

PrintBar .... ?, заказываешь и через 2 недели за 2 тыс у тебя

хух)

А я то надеялся на халявную лавочку) Уж очень халява притягательна =3

их рекламы как грязи ... уже! Материал говно ... качество исполнения на высоте

всм принт шопов?

да и там в конструкторе ... сам картинки добавляешь

Хе) а картиночка долго держится?

да ... химия там качественная!

хмм... надо бы заказать что ли...