Здравствуйте, Sinclair, Вы писали:

V>>Это с рождения условие существования.
V>>(тут маты, маты, маты...)
S>А должны быть ссылки, ссылки, ссылки. Увы.

Кому должны?


V>>Буквально одной извилинкой шевельни — иначе как бы одни и те же программы или либы запросто распространялись что-то под сотню одновременно существующих сегодня независимых пакетных менеджеров и даже несколькими десятками сдохших на сегодня?
S>Да я-то шевельнул. Не очень понятно, что имеется в виду под "программа не знает о пакете".

Это одна из практик проектирования ПО, только здесь в области деплоя.
То бишь, конечные библиотеки и программы не должны самостоятельно заботиться о своём обновлении.

Понятно, что в Windows это десятилетиями было не так, отсюда у тебя сложности с пониманием пресловутого unix way.
Но в UWP уже так, а до этого так стало в iOS и Android.


S>В бинаре, понятное дело, никаких следов пакетного менеджера нет.

В виндовых классических Win32 API программах часто сидит собственный/уникальный менеджер пакета, связанный с некоей личной точкой деплоя в сети.


S>А вот с точки зрения сборки и поставки — сейчас собственно "программа" или "библиотека" и есть пакет.

Пакет — это не просто целевые программы/библиотеки, а еще некоторая метаинформация сверху, необходимая пакетному менеджеру.


S>То есть именно он является результатом труда разработчика. Сборка пакета является частью билд-системы, за которую отвечает собсно исходный автор.

Не всегда, вернее, почти никогда.

Ментейнеры линухов собирают свои сборки из многих тысяч программ/библиотек.
И тот факт, что программы "не знают" о пакетах как раз позволяет это делать.


S>Те случаи, когда опакечивание выполняется посторонними, являются частным случаем — просто исходники собственно кода разрабатывает кто-то другой.

Это мейнстримовый случай в никсах чуть ли не от рождения.


S>Т.е. вот я являюсь автором пакета, который сам при сборке зависит от чего-то внешнего — например, исходников, вытащенных из гитхаба или битбакета. Или бинарей, которые уже были кем-то собраны для моей целевой архитектуры, но не оформлены для моего пакетного менеджера.

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


S>Поэтому никакого предусловия типа "автор исходного проекта не знает о пакетном менеджере" нет и быть не может.

Смело, лихо...

Тебе разве в детстве не говорили, что Деда Мороза не существует?
Вот, говорю.


V>>Поэтому на выходе произведение.
V>>А задачей пакетных менеджеров отродясь было давать сумму.
S>Вы, похоже, не понимаете основную мысль.

В трёх соснах заблудился ты, а не понимаю я? ))
Молодец, чо!

Еще раз (в третий) — в описанной Алексом системе каждая программа/либа тащит с собой свои зависимости.
Неважно, статически или динамически линкованные, в последнем случае тащит их как файлы, копируемые в некую личную для программы директорию.

Это как выполнить dotnet publish — и все зависимости скопировались с твоей программой.
У второй программы dotnet publish опять скопирует зависимости.
...
У десятой аналогично.
Поэтому — произведение.

В классическом unix way зависимости повторно не тащат, поэтому на выходе сумма.

Доходчиво на пальцах объяснил?

Здравствуйте, Sinclair, Вы писали:

V>>Это с рождения условие существования.
V>>(тут маты, маты, маты...)
S>А должны быть ссылки, ссылки, ссылки. Увы.

Кому должны?


V>>Буквально одной извилинкой шевельни — иначе как бы одни и те же программы или либы запросто распространялись что-то под сотню одновременно существующих сегодня независимых пакетных менеджеров и даже несколькими десятками сдохших на сегодня?
S>Да я-то шевельнул. Не очень понятно, что имеется в виду под "программа не знает о пакете".

Это одна из практик проектирования ПО, только здесь в области деплоя.
То бишь, конечные библиотеки и программы не должны самостоятельно заботиться о своём обновлении.

Понятно, что в Windows это десятилетиями было не так, отсюда у тебя сложности с пониманием пресловутого unix way.
Но в UWP уже так, а до этого так стало в iOS и Android.


S>В бинаре, понятное дело, никаких следов пакетного менеджера нет.

В виндовых классических Win32 API программах часто сидит собственный/уникальный менеджер пакета, связанный с некоей личной точкой деплоя в сети.


S>А вот с точки зрения сборки и поставки — сейчас собственно "программа" или "библиотека" и есть пакет.

Пакет — это не просто целевые программы/библиотеки, а еще некоторая метаинформация сверху, необходимая пакетному менеджеру.


S>То есть именно он является результатом труда разработчика. Сборка пакета является частью билд-системы, за которую отвечает собсно исходный автор.

Не всегда, вернее, почти никогда.

Ментейнеры линухов собирают свои сборки из многих тысяч программ/библиотек.
И тот факт, что программы "не знают" о пакетах как раз позволяет это делать.


S>Те случаи, когда опакечивание выполняется посторонними, являются частным случаем — просто исходники собственно кода разрабатывает кто-то другой.

Это мейнстримовый случай в никсах чуть ли не от рождения.


S>Т.е. вот я являюсь автором пакета, который сам при сборке зависит от чего-то внешнего — например, исходников, вытащенных из гитхаба или битбакета. Или бинарей, которые уже были кем-то собраны для моей целевой архитектуры, но не оформлены для моего пакетного менеджера.

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


S>Поэтому никакого предусловия типа "автор исходного проекта не знает о пакетном менеджере" нет и быть не может.

Смело, лихо...

Тебе разве в детстве не говорили, что Деда Мороза не существует?
Вот, говорю.


V>>Поэтому на выходе произведение.
V>>А задачей пакетных менеджеров отродясь было давать сумму.
S>Вы, похоже, не понимаете основную мысль.

В трёх соснах заблудился ты, а не понимаю я? ))
Молодец, чо!

Еще раз (в третий) — в описанной Алексом системе каждая программа/либа тащит с собой свои зависимости.
Неважно, статически или динамически линкованные, в последнем случае тащит их как файлы, копируемые в некую личную для программы директорию.

Это как выполнить dotnet publish — и все зависимости скопировались с твоей программой.
У второй программы dotnet publish опять скопирует зависимости.
...
У десятой аналогично.
Поэтому — произведение.

В классическом unix way зависимости повторно не тащат, поэтому на выходе сумма.

Доходчиво на пальцах объяснил?

==============
Вдогонку — и да, в одной системе могут существовать одни и те же либы разных своих версий.