Zgodność sprzętu z Linuksem > Urządzenia wielofunkcyjne
EPSON L3070 - Drukarka[OK] Skaner[?]
pavbaranov:
Każda aplikacja 32bit działa w systemie 64bit jeśli ten udostępnia tzw. biblioteki multilib. Odwrotnie - nie jest to możliwe.
Cóż. W przypadku 32-bit Tumbleweed masz do dyspozycji praktycznie wyłącznie skompilować sobie sterownik. Bądź zmienić system na 64bit. Wybór należy do Ciebie.
1709:
" Chyba mocno słabo szukasz "
pavbaranov Bo nie ma ich tam gdzie powinny być, czyli na stronie producenta po wpisaniu modelu drukarki
https://www.epson.pl/support?productID=22120&os=12#drivers_and_manuals
Ktos by musial skarge napisac zeby poprawili jesli mogą.
" Póki co, zostaję przy 32 bitach. "
Jesli ilosc miejsca pozwoli,
to chyba łatwiej będzie zainstalować obok drugi system np. Debiana 32bit niż się męczyć z piętrowymi zależnościami, czy kompilacja pakietów.
Nie mam zielonego pojęcia ile podstawowa instalacja + aktualizacje maga zając.
https://www.debian.org/releases/jessie/amd64/ch03s04.html.en
" To, że jakaś dystrybucja wykorzystuje system paczkowania RPM nie oznacza, że można paczki z jednej dystrybucji używać w innej. "
pavbaranov Generalnie masz racje.
Ale prawda jest tez taka, ze jeśli ktoś ma " ambicje / silne nerwy / dużo czasu " to spróbuje mimo ogromu zależności.
Przykładem jest projekt Alien konwertujący pakiety.
- OpenSuse ma menadżer pakietowania w którym można dopasować zależności, w zależności od wykrytej dystrybucji Linuxa.
Przykładem jest LibreOffice.
Wiec gdyby tak zrobili sterowniki rpm, to może wystarczyłaby jedna paczka dla wszystkich dystrybucji rpm.
Problemem jest fakt ze nazwy zależności czasem lubią się zmieniać, a bez sensu by było żeby OpenSuse taka bazę nazw gromadziło,
może kiedyś ktoś wpadnie na pomysł wykonania skryptu, żeby sprawdzał zależności prosto z danego repozytorium.
Ponieważ nazwy plików raczej będą takie same w każdej dystrybucji Linuxa.
( bibliotek może brakować jeśli program został skompilowany bez danej opcji )
Problemem także mogą być czasem wersje bibliotek, bo muszą posiadać potrzebne "funkcje".
Zazwyczaj nowsze biblioteki maja 100% starych funkcji, ale czasem są bardziej zmodyfikowane i może być klops.
Wiem ze ręczne linkowanie bibliotek, tak jak użycie Alien-a może pomoc w uruchomieniu programu, jak i nie pomoc
i zniszczyć cały misterny plan i godziny pracy. Juz nie wspominając o bałaganie w systemie
i ewentualnych przyszłych problemach z aktualizacjami.
pavbaranov:
@1709 - Obawiam się, że alien nie przerobi *.rpm z Fedory na *.rpm OpenSUSE. W ogóle przy tego typu przeróbkach musimy pamiętać o:
1. konwersji podlega paczka binarna (skompilowana),
2. pliki wykonywalne są często kompilowane przy użyciu określonych narzędzi i w oparciu o określone wersje swoich zależności,
3. w wyniku kompilacji co najmniej część plików wykonywalnych będzie do swojego uruchomienia wymagać zależności w określonej wersji (tej, na której została skompilowana),
4. konwersja nie spowoduje "zamiany", że jakaś binarka wymagająca jakiejś zależności w określonej wersji zadziała na wersji, która dostarczona jest wraz z systemem.
Innymi słowy użycie aliena do przebudowy paczki np. Debiana na rpm (niestety alien "nie wie", czy ten rpm ma być "fedorowy", "mandrivowy", czy "opensuse" itd.) może, ale nie musi się udać, zwłaszcza, że biblioteki (które są najczęściej zależnościami takich sterowników) w Tumbleweed są jakieś pewnie 2 lata "nowsze" od wersji w Debianie.
Zwróćcie jeszcze uwagę na treść: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/imagescan gdzie jest przykład kompilacji na Archa. Jak widać podczas prekompilacji przekazuje się kompilatorowi takie informacje jak np. miejsce położenia binarki w systemie (może być różne w OpenSUSE oraz innych systemach, z których paczka miałaby być skonwertowana). Także informacja zawarta w zmianach paczki: https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/imagescan wskazuje, że paczka podlega przebudowie wraz z dostarczeniem do niego nowej wersji boost. Dodatkowo sam boost wymaga przebudowy w zależności od poppler, icu oraz pythona: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/boost. I tak dalej.
Można zatem próbować, ale czy będzie to działać?
Rolling release są fajnymi systemami, ale jednakże jeśli jakiejś paczki w nim nie ma (dla niego nie ma), to trzeba się nieco bardziej natrudzić.
Paweł Kraszewski:
Tutaj masz paczkę SRPM do skanera, do własnej kompilacji. Prawdopodobnie zadziałają na Twoim systemie i wygenerują poprawną paczkę 32-bitową - w pliku SPEC nie widziałem nic blokującego 32 bity. Dalej nie pomogę, bo jestem wyznania debianowego i nie znam liturgii do generacji RPM z SRPM.
pavbaranov:
Źródła budują się na 32bit na 100% (zob. m.in.: https://archlinux32.org/packages/?q=imagescan). Zatem to co Paweł podesłał to już 90% roboty. Reszta to już kompilacja. Masz np. tu: . Ogólnie winno to się sprowadzić do:
--- Kod: ---
mkdir imagescan
cd imagescan
wget http://support.epson.net/linux/src/scanner/imagescanv3/opensuse/imagescan-3.62.0-1epson4opensuse15.1.src.rpm
rpmbuild --rebuild imagescan-3.62.0-1epson4opensuse15.1.src.rpm
--- Koniec kodu ---
Potem już instalacja zypperem i... modlenie się w wyznaniu rpmowym, by paczka, która jest źródłami teoretycznie dla Leap 15.1 poprawnie się zbudowała i działała w Tumbleweed.
Jeśli to się nie powiedzie (wątpię), to są jeszcze "ogólne" źródła ale kompilacja nie będzie już tak miła i prosta.
Nawigacja
[#] Następna strona
Idź do wersji pełnej