Najpierw kiepska odpowiedź: to zależy
Jeśli wypuszczasz pliki binarne, załóż, że odpowiedź brzmi „nie”, chyba że rozpowszechniasz wszystkie biblioteki, które kiedykolwiek się z tym wiążą (od podstaw, co jest denerwujące, chyba że zapewniasz naprawdę ogromny system, który i tak działa samodzielnie) ) lub statycznie łączą ekwiwalent.
... ale czarodzieje i pieniądze i czarodzieje pieniądze ...
IBM ma kilka „ogólnych uniksowych” instalatorów, które zszokowały mnie, pracując wszędzie, gdzie ich wypróbowałem: kilka Linuces z kilku generacji jądra, OpenSolaris (lub jak to się teraz nazywa), Solaris i BSD. Ale są ogromne. A rzeczy, które zapewniają, są równie ogromne. W ten sposób nie są publikowane żadne małe programy wyścigowe, tylko duże korporacyjne rzeczy, których można oczekiwać od IBM.
Jeśli chodzi tylko o pozostawanie w systemie Linux, ale działa dobrze w większości Linuxdom, wydaje się, że jest to możliwe w formie binarnej, o czym świadczy różnorodność instalatorów binarnych typu „dla Linux (ogólnie)”, które zobaczysz od niektórych dostawców. Kilka czatów, przeglądarek, gier, meta-instalatorów itp. Jest publikowanych w ten sposób, ale zawsze przez wielkich sprzedawców, którzy mogą poświęcić czas, aby to zrobić. To niesamowite, że mogą powiedzieć „dla Linuksa” i ogólnie są pewni, że zadziała, ale wydaje się, że tak jest.
Ale...
Rozpowszechniam moje oprogramowanie jako źródło za pomocą narzędzia do kompilacji. Zrobić to w C, Erlang, Python, Guile, itp Daje mi dużo większą elastyczność na temat tego, czy to będzie działać czy nie, a to jest o wiele łatwiej napisać buildscript sprawia, że na pewno właściwe rzeczy istnieją w czasie kompilacji, niż upewnij się, że wszystko jest na swoim miejscu w czasie wykonywania. Gdy już to istnieje, napisanie automatycznego programu aktualizującego dla twojego programu jest proste, jeśli dystrybuujesz źródło: źródło jest zwykle dużo mniejsze niż plik binarny, który zawiera wszystkie deps i inne szaleństwa. Korzystając z tej metody, nie miałem większych problemów z niezawodnym wdrożeniem na Unices (a czasem Windowsie, ale to trochę więcej pracy).
Dość zabawy dla dzieci, uzbrój się!
Kiedy poważnie podchodzisz poważnie, jak srsly srs, do płynnego dopasowania się do świata Linuksa, dystrybuujesz źródła C lub przechodzisz do w pełni zarządzanego środowiska, aby uzyskać zachwycająco zachwycający język, który jest już wstępnie zbudowany. Jeśli piszesz na przykład kod Python, możesz sprawdzić wersje i dowiedzieć się, z którą wersją CPython współpracujesz, i ogólnie oczekiwać, że na danym systemie Linux będzie istniała kompatybilna wersja (i jest to o wiele łatwiejsze do sprawdzenia niż szeroki zakres bibliotek C / wersje, których możesz używać). Erlang, Guile, Python, Perl, CL itd. Są bardzo podobne łatwe cele dla tego rodzaju wdrożenia, a wiele z nich ma centralne repozytorium, takie jak CPAN lub pip (lub cokolwiek innego), w którym użytkownicy mogą uruchomić polecenie, aby samodzielnie pobrać podpisane źródło, i wiedzą, że rzeczy będą na ogół działać zgodnie z zamierzeniami .
[Dodatek: 1. Nawet Haskell może to generalnie wykonać za pośrednictwem Cabala - chociaż byłbym ostrożny w robieniu tego w środowisku produkcyjnym. 2. Istnieją całkowicie różne strategie wdrażania „wydania” w Erlang, które gwarantują, że Twój kod niesie ze sobą kompletne środowisko. 3. Python idzie o krok dalej w środowiskach wirtualnych; nie wszystkie środowiska wykonawcze pomagają ci tak bardzo.]
Ten ostatni fragment dotyczący środowisk zarządzanych w systemie Linux jest niesamowity . Jako bonus umożliwia zdefiniowanie znacznie bardziej ogólnych zależności, automatyczne ich rozwiązywanie bez dodatkowego wysiłku z Twojej strony, nie wymaga pisania paczki dla każdej dystrybucji i możesz przestać dbać o to, czy system ma 32 czy 64 bit (ogólnie zresztą).