Problem z instalacja kadu
Sulsa
taki blad:
[root@localhost sulsa]# rpm -ihv kadu-alsa_sound-0.4.2-1.fc4.i386.rpm
kadu-0.4.2-1.fc4.i386.rpm
błąd: Niespełnione zależności:
libsndfile.so.1 jest wymagany przez kadu-0.4.2-1.fc4.i386
libsndfile.so.1(libsndfile.so.1.0) jest wymagany przez
kadu-0.4.2-1.fc4.i386
biblioteke libsndfile skompilowalem i zainstalowalem wlasnorecznie, wiec
czemu system jej nie widzi?
[root@localhost sulsa]# find / -name 'libsndfile*'
/usr/local/lib/libsndfile.so.1.0.12
/usr/local/lib/libsndfile.a
/usr/local/lib/libsndfile.so.1
/usr/local/lib/libsndfile.so
/usr/local/lib/libsndfile.la
Hoppke
has been fingerprinted by Sulsa:
> biblioteke libsndfile skompilowalem i zainstalowalem wlasnorecznie,
> wiec czemu system jej nie widzi?
RPM, nie "system". RPM "widzi" tylko to, co zostało zainstalowane z
pakietu rpm. Skoro się już bawisz w kompilację, to skompiluj sobie też
kadu. A jeśli chcesz używać kadu z pakietów, to i libsndfile zainstaluj
z pakietu. Proste :)
--
.°.°.°.°.°.°.: http://dobremiasto.net/~hoppke/ :.°.°.°.°.°.°.
Sulsa
> Message diqo9i$56g$1...@inews.gazeta.pl
> has been fingerprinted by Sulsa:
>
>> biblioteke libsndfile skompilowalem i zainstalowalem wlasnorecznie,
>> wiec czemu system jej nie widzi?
>
> RPM, nie "system". RPM "widzi" tylko to, co zostało zainstalowane z
> pakietu rpm. Skoro się już bawisz w kompilację, to skompiluj sobie też
> kadu. A jeśli chcesz używać kadu z pakietów, to i libsndfile zainstaluj
> z pakietu. Proste :)
>
Chacialem bardziej hardcorowo zainstalowac ja ze zrodel. Jesli jest tak jak
mowisz, a wyglada na to ze jest, to troche kulawy ten rpm.
argothiel
> Hoppke wrote:
>> RPM "widzi" tylko to, co zostało zainstalowane z pakietu rpm. Skoro
>> się już bawisz w kompilację, to skompiluj sobie też kadu. A jeśli
>> chcesz używać kadu z pakietów, to i libsndfile zainstaluj z pakietu.
>> Proste :)
Może (;)) w jakimś pliku są zapisane informacje o zainstalowanych
pakietach i wystarczy wyedytować ten plik?
Pozdrawiam, argothiel
Hoppke
has been fingerprinted by argothiel:
> Może (;)) w jakimś pliku są zapisane informacje o zainstalowanych
> pakietach i wystarczy wyedytować ten plik?
Oczywiście. Pliki te znajdują się w /var/lib/rpm, mają format bodajże
Berkeley DB, układ i znaczenie kluczy zgodne ze standardami RPM-a.
Najłatwiej bazę danych zmienić za pomocą rpm-a, importując do bazy nowy
pakiet. Wyedytowanie bazy przez "rpm -Uvh nowypakiet.rpm" jest IMO
najprzyjaźniejsze userowi :)
dawid gajownik
> Chacialem bardziej hardcorowo zainstalowac ja ze zrodel.
To nie jest hardcorowa instalacja programów, a tylko zwykłe śmiecenie w
systemie. Już kilka razy widziałem, jak programu potrafiły nadpisywać
pliki z innych programów lub zostawiały jakieś resztki po odinstalowaniu.
Paczkowanie programów pozwala na uniknięcie tego problemu.
Do tego dochodzi kwestia bezpieczeństwa - będziesz śledził BugTraq,
Secunia czy coś innego, by dowiedzieć się czy w jakiejś aplikacji, która
leży gdzieś na dysku, nie ma jakiejś luki? Będziesz potem przeszukiwał
grupy mailingowe danych projektów lub ich repozytoria CVS/SNV/git/whatever
by znaleźć łatkę? Tak się składa, że najnowsza wersja programu wcale nie
oznacza, iż jest załatana i wolna od luk.
Obserwując niektórych moich znajomych oraz wypowiedzi pewnych osób na
forach oraz grupach mailingowych/usenetowych zauważyłem, iż po
zainstalowaniu programu zwykle “olewają” ten problem. “Skoro działa to po
co ruszać?” - zwykle słyszę tę śpiewkę. No tak, a potem czyta się, że
znowu włamano się na jakiegoś Linuksa i że lepiej zainstalować coś z
rodziny *BSD i takie tam...
Korzystanie z repozytoriów ze spaczkowanymi programami zwalnia użytkownika
z patchowania. O dany program dba jakiś deweloper, który zwykle
współpracuje z deweloperami danej aplikacji i trzyma zawsze rękę na
pulsie.
Na dodatek programy kompilowane ręcznie mają zwykle gorszą wydajność niż
te z paczek. Tak się składa, że początkujący zwykle bez zastanowienia
przepisują z jakichś tam porad znalezionych w internecie instrukcje,
których w ogóle nie rozumieją. Myślą, że jak wpiszą `./configure && make
&& make install' to wszystko będzie cacy. Niby skąd mają wiedzieć, że
należy ustawić poprawnie zmienne CFLAGS, CXXFLAGS, LDFLAGS? Podczas
budowania RPM-ów te zmienne są zawsze ustawiane (przykładowo w Fedorze dla
platformy i386 są takie:"-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=pentium4 -fasynchronous-unwind-tables").
Na koniec jeszcze warto wspomnieć o procesie aktualizacji. Zmieniając
jakąś bibliotekę na nowszą zwykle będziesz musiał przekompilować zależne
od niej programy. Przy ręcznej kompilacji nigdy nie będziesz miał
pewności, że o czymś nie zapomniałeś (nie będziesz miał żadnych zależności
tak jak w systemie z obsługą pakietów). Prawdopodobieństwo wysypania się
jakiegoś programu wtedy wzrasta.
> Jesli jest tak jak mowisz, a wyglada na to ze jest, to troche kulawy ten
> rpm.
RPM korzysta z bazy danych (zwykle jest umieszczona w /var/lib/rpm). Żeby
coś się tam znalazło, to musi być w jakiś sposób tam dodane. Teoretycznie
RPM mógłby szukać wszystkiego na dysku, ale byłoby to bardzo nieefektywne.
Polecenie szukające zależności musiałoby sprawdzić czy nie dodano jakichś
nowych plików, przemielić binarki poleceniem `ldd', itd. Trwałoby to dość
długo. A co z innymi zależnościami, których nie można w ten sposób
sprawdzić?
Ja nie widzę problemu w obecnym sposobie działania. Wystarczy tylko
instalować same RPM-y i nie śmiecić w systemie. Jak paczek nie ma, to
zawsze można je zrobić.
--
http://faq.fedora.pl
http://forum.fedora.pl
http://openwengo.com/ - i Ty możesz pomóc zniszczyć niewolnego Skype'a ;)
Sulsa
> [Wielkie ciach]
Dziwi mnie ze chcialo ci sie tyle pisac, ale dzieki za odpowiedz,
przekonales mnie zeby nie zgrywac hackera tylko wszystko po lamersku z
rpmow instalowac, ta biblioteke instalowalem ze zrodel tak na probe, bo
kiedys mialem problem z instalacja pakietu, ktory zalezal od bibliotek
instalowanych ze zrodel i teraz chcialem sie troszeczke poduczyc. A z tym
rpmem poradzilem sobie za pomoca flagi --nodeps
dawid gajownik
> przekonales mnie zeby nie zgrywac hackera tylko wszystko po lamersku z
> rpmow instalowac,
Dlaczego po lamersku? Ułatwianie sobie życia nie jest lamerskie. Możesz
wtedy przeznaczyć czas na coś bardziej pożytecznego (zrobienie
właściwej pracy, zgłaszanie błędów w programach, pomoc w rozwoju
Wolnego Oprogramowania czy cokolwiek innego co jest dla Ciebie ważne).
A jeśli jakieś RPM-y Ci się nie podobają, to zawsze możesz je
zmodyfikować :)
> A z tym rpmem poradzilem sobie za pomoca flagi --nodeps
Czyli według zasady: “Nic na siłę tylko młotkiem” ;-) Opcje --nodeps czy
--force czasami się przydają, ale w Twoim wypadku niepotrzebnie ich
użyłeś. W 99.9% powodują więcej szkody niż pożytku. Wystarczyło wklepać:
yum install libsndfile
http://fedora.redhat.com/docs/yum/
http://wiki.fedora.pl/Administracja/Yum
Tomek
> systemie. Już kilka razy widziałem, jak programu potrafiły nadpisywać
> pliki z innych programów lub zostawiały jakieś resztki po odinstalowaniu.
>
> Paczkowanie programów pozwala na uniknięcie tego problemu.
>
W 99,9% się z tobą zgodzę, ale ....
Np. w przypadku kadu jak chcę dodatkowe moduły to bez kompilacji się nie
odbędzie ale...
Zawsze można ze zródeł stworzyć własną paczkę dla zachowania zgodności.
Także komplacja programów ze źródeł ma sens tylko wtedy jak potrzeba coś
więcej niż zawiera standartowo paczka rpm.
Tomek
dawid gajownik
> Np. w przypadku kadu jak chcę dodatkowe moduły to bez kompilacji się nie
> odbędzie ale...
A czy ja gdzieś bronię kompilacji kodu? Po to są źródła, by je
modyfikować. Pisząc “kompilacja ze źródeł” mam zawsze na myśli wklepywanie
“./configure && make && make install” - tego sposobu instalacji zawsze
będę odradzał, bo pozwala na niekontrolowane nadpisywanie istniejących
plików oraz prowadzi do bałaganu w systemie (czasami deweloperzy robią
błędy w Makefile'ach).
Jak ktoś nie chce poświęcić chwili czasu na naukę budowy RPM-ów, DEB-ów
czy ebuildów, to niech korzysta przynajmniej z programów typy
checkinstall. Tworzone w ten sposób paczki może nie są najlepszej jakości,
ale lepsze to niż nic.
> Zawsze można ze zródeł stworzyć własną paczkę dla zachowania zgodności.
Strata czasu. Zmodyfikowanie gotowego już SRPM-a zwykle sprowadza się do
kilku zmian w sekcji `%build' oraz `%files', więc tworzenie wszystkiego od
nowa mija się trochę z celem.
> Także komplacja programów ze źródeł ma sens tylko wtedy jak potrzeba coś
> więcej niż zawiera standartowo paczka rpm.
O tym problemie wspomniałem już tutaj →
pan.2005.10.15....@N05P4M.poczta.onet.pl Ważne jest tylko
dbanie o łatanie własnoręcznie przygotowanych pakietów. Jak ktoś
potrzebuje dostosować większą ilość programów do swoich potrzeb, to niech
zainstaluje Gentoo, ustawi zmienną USE, a resztą zajmie się Portage :)
Instalowanie wszystkiego “ze źródeł” w pakietowej dystrybucji mija się z
celem - traci się wtedy wszystkie korzyści wynikające z pakietów.
Jakub Panachida
>> Także komplacja programów ze źródeł ma sens tylko wtedy jak potrzeba coś
>> więcej niż zawiera standartowo paczka rpm.
>
> pan.2005.10.15....@N05P4M.poczta.onet.pl Ważne jest tylko
> dbanie o łatanie własnoręcznie przygotowanych pakietów. Jak ktoś
> potrzebuje dostosować większą ilość programów do swoich potrzeb, to niech
> zainstaluje Gentoo, ustawi zmienną USE, a resztą zajmie się Portage :)
>
> celem - traci się wtedy wszystkie korzyści wynikające z pakietów.
uwzględnianie własnych patchy przy wyjściu nowego pakietu źródłowego?
Przykładowo chciałbym żeby każda nowa wersja masqmail-a była zbudowana
z moimi patchami, a każdy nowy rxvt miał włączoną obsługę resourców
z /etc/X11/app-defaults, bez potrzeby ręcznego dodawania patchy za
każdym razem?
--
Jakub Panachida
Tomek
> On Sat, 15 Oct 2005 20:55:08 +0200, Tomek wrote:
>>Zawsze można ze zródeł stworzyć własną paczkę dla zachowania zgodności.
>
>
> Strata czasu. Zmodyfikowanie gotowego już SRPM-a zwykle sprowadza się do
> kilku zmian w sekcji `%build' oraz `%files', więc tworzenie wszystkiego od
> nowa mija się trochę z celem.
A czy ja pisałem gdzieś o srpm ? (Pisałem ogólnie o źródłach)
>
>>Także komplacja programów ze źródeł ma sens tylko wtedy jak potrzeba coś
>>więcej niż zawiera standartowo paczka rpm.
>
>
> O tym problemie wspomniałem już tutaj →
> pan.2005.10.15....@N05P4M.poczta.onet.pl Ważne jest tylko
> dbanie o łatanie własnoręcznie przygotowanych pakietów. Jak ktoś
> potrzebuje dostosować większą ilość programów do swoich potrzeb, to niech
> zainstaluje Gentoo, ustawi zmienną USE, a resztą zajmie się Portage :)
>
> Instalowanie wszystkiego “ze źródeł” w pakietowej dystrybucji mija się z
> celem - traci się wtedy wszystkie korzyści wynikające z pakietów.
>
Ja nie należę do masochistów którzy musza wszystko kompilować sami, jak
pisałem wyżej zgadzam się z tobą w 99,9% jednak są przypadki jak np.
wspomniane kadu gdy kompilacja jest potrzebna.
Innym przypadkiem jest kompilacja jadra sytemu, ostatnio zmieniłem dysk
na SATA i niestety w dystrybucyjnym jajku tego nie ma, do tego dochodzi
patch-o-matic, stery np. nvidia.
Niedługo mam zamiar dokupić drugi taki sam dysk i zrobic macierz raid i
też trzeba bedzie niestety kopilowac jajko, bo dystrybucyjne tego nie ma.
Także jestem za kopilacją tylko w przypadkach szczególnych, bo w pełni
polegam na rpm i doświadczeniu ludzi je budujących a stanowczo odradzam
kopilację bibliotek systemowych, no chyba że jest bardzo dużo konketnych
powódów innych niż chcę "hardcorowo" to zrobić bo tak chcę.
Tomek
dawid gajownik
> Czy któryś z wymienionych przez Ciebie systemów pakietów pozwala na
> uwzględnianie własnych patchy przy wyjściu nowego pakietu źródłowego?
Moja wiedza jest zbyt mała, by móc odpowiedzieć na to pytanie, ale wydaje
mi się, że nie.
Jak mi czegoś brakuje w danym programie/pakiecie, to zgłaszam zwykle to w
Bugzilli/Mantisie danego projektu. Przykładowo, udało mi się tak już
wepchnąć kilka patchy (tych moich i tych z PLD) do programu Gajim. Wydaje
mi się, że na dłuższą metę jest to rozwiązanie najmniej uciążliwe dla
użytkownika.
Jeśli program wymaga innych opcji kompilacji, to zawsze można poprosić
dewelopera danej paczki o dodanie paru linijek w pliku spec pozwalających
na budowanie warunkowe¹
¹ http://dobremiasto.net/~hoppke/too_much_to_learn/rpm/3_07.html
dawid gajownik
> A czy ja pisałem gdzieś o srpm ? (Pisałem ogólnie o źródłach)
A to przepraszam. Musiałem źle przeczytać.
> Innym przypadkiem jest kompilacja jadra sytemu, ostatnio zmieniłem dysk
> na SATA i niestety w dystrybucyjnym jajku tego nie ma
Można wiedzieć co to za dystrybucja? Wydawało mi się, że takie
podstawowe rzeczy są w każdym firmowym jajku w postaci modułów. Potem
wystarczy tylko wygenerować nowy initrd.
> stery np. nvidia.
To mnie zaciekawiło - można wiedzieć co zmieniałeś w konfiguracją jądra?
Nigdy nie musiałem rekompilować kernela, by zainstalować te zawieszające
system sterowniki ;-)
Jakub Panachida
> On Sun, 16 Oct 2005 13:33:33 +0200, Jakub Panachida wrote:
>
>> Czy któryś z wymienionych przez Ciebie systemów pakietów pozwala na
>> uwzględnianie własnych patchy przy wyjściu nowego pakietu źródłowego?
>
> Moja wiedza jest zbyt mała, by móc odpowiedzieć na to pytanie, ale wydaje
> mi się, że nie.
> Jak mi czegoś brakuje w danym programie/pakiecie, to zgłaszam zwykle to w
> Bugzilli/Mantisie danego projektu.
Czasami projekt nie jest już rozwijany. Dość często nie przynosi to żadnego efektu, nawet odmownej odpowiedzi. Próbowałem kiedyś skontaktować się z maintenerem masqmaila z Debiana -- równie dobrze mógłbym korespondować z /dev/null.
> Przykładowo, udało mi się tak już
> wepchnąć kilka patchy (tych moich i tych z PLD) do programu Gajim. Wydaje
> mi się, że na dłuższą metę jest to rozwiązanie najmniej uciążliwe dla
> użytkownika.
Racja. Tyle, że ja mam dość nietypowe wymagania, np. używam utf-8,
a parę lat temu dystrybucje nie były tym zainteresowane.
> Jeśli program wymaga innych opcji kompilacji, to zawsze można poprosić
> dewelopera danej paczki o dodanie paru linijek w pliku spec
> pozwalających na budowanie warunkowe??
>
> ?? http://dobremiasto.net/~hoppke/too_much_to_learn/rpm/3_07.html
RPMa znam bardzo dobrze. Niestety po wersji 4.1 zaczął mieć coraz więcej
zależności, binarna baza pakietów psuła się często, a każda dystrybucja
go modyfikowała inaczej i mocno. Na dodatek miał on sporo błędów
i martwego kodu. Wtedy wziąłem się za hbs, którego używam do dzisiaj.
Równie dobrze znam pkgtools, ale jeśli chodzi o budowanie pakietów, to
system ten ma prawie same wady.
Słabo natomiast znam apt. Dzisiaj na 7thguardzie pojawił się jednak
artykuł, który dale mi nadzieję: http://7thguard.net/news.php?id=4737,
akapit zatytułowany "Lokalne utrzymanie zmian w pakietach Debianowych."
--
Jakub Panachida
dawid gajownik
> Czasami projekt nie jest już rozwijany.
Wtedy nie ma też tego problemu z ciągłymi aktualizacjami i ciągłym
patchowaniem ;-)
> Próbowałem kiedyś skontaktować się z maintenerem masqmaila z Debiana --
> równie dobrze mógłbym korespondować z /dev/null.
Heh, wszystko zależy od osoby na jaką się trafi :/ Mi się osobiście nigdy
nie udało uzyskać odpowiedzi od fedorowych deweloperów kernela. Zwykle
mają na głowie ponad kilkaset zgłoszeń o błędach, więc są zawsze zabiegani...
Z innymi na szczęście było znacznie lepiej :D
> Racja. Tyle, że ja mam dość nietypowe wymagania, np. używam utf-8, a
> parę lat temu dystrybucje nie były tym zainteresowane.
Zgodnie z tym postem →
http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html to
Etch powinien wreszcie przejść na UTF-8. Jak dobrze pójdzie, to będziesz
miał jeden patch mniej do nakładania ;)
> RPMa znam bardzo dobrze. Niestety po wersji 4.1 zaczął mieć coraz więcej
> zależności, binarna baza pakietów psuła się często, a każda dystrybucja
> go modyfikowała inaczej i mocno. Na dodatek miał on sporo błędów i
> martwego kodu.
Jakby na to nie patrzeć, to już jest wersja 4.4.2 i sporo od tamtego czasu
się pozmieniało :)
> Wtedy wziąłem się za hbs, którego używam do dzisiaj.
Używasz LFS?
> Słabo natomiast znam apt. Dzisiaj na 7thguardzie pojawił się jednak
> artykuł, który dale mi nadzieję: http://7thguard.net/news.php?id=4737,
> akapit zatytułowany "Lokalne utrzymanie zmian w pakietach Debianowych."
Ha, no tego nie znałem. Dzięki!
Jakub Panachida
>> Czasami projekt nie jest już rozwijany.
>
> Wtedy nie ma też tego problemu z ciągłymi aktualizacjami i ciągłym
> patchowaniem ;-)
nie znajduje nowych błędów. A gdy używałem Slackware za każdym razem gdy
pojawiła sie poprawka, a tym samym nowa paczka, musiałem sam zmieniać
pakiet. Po pewnym czasie zauważyłem, że tych przeróbek robi się dużo
i warto je zautomatyzować.
>> Próbowałem kiedyś skontaktować się z maintenerem masqmaila z Debiana --
>> równie dobrze mógłbym korespondować z /dev/null.
>
> Heh, wszystko zależy od osoby na jaką się trafi :/
Prawda. Czasami poprawkę naniosą w ciągu jednego dnia. Zaznaczam, że ja
wysyłam jedynie patche nie zajmujące więcej niż jeden ekran, nie żadne
rozbudowane przeróbki.
> Zgodnie z tym postem ???
> http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html to
> Etch powinien wreszcie przejść na UTF-8. Jak dobrze pójdzie, to będziesz
> miał jeden patch mniej do nakładania ;)
Dodatkowo ja buduję pakiety jedynie z gtk+2, a Debian z gtk+1,
a rozbieżności jest więcej.
> Jakby na to nie patrzeć, to już jest wersja 4.4.2 i sporo od tamtego czasu
> się pozmieniało :)
Kto raz przejdzie na hbs ma wygórowane wymagania, więc dopóki nie dowiem
się że oferuje coś przełomowego to nie mam ochoty go oglądać.
A tak przy okazji -- skąd masz wersję 4.4.2? http://rpm.org/ podają jako
najnowszą wersję 4.2. Jeśli w CVSu, to jest to kolejna rzecz, która mnie
do tego systemu pakietów zniechęciła -- dystrybucje brały kod z CVS
i dawały swoje własne numerki, mając niezgodny kod pomiędzy sobą.
>> Wtedy wziąłem się za hbs, którego używam do dzisiaj.
>
> Używasz LFS?
Tak. Dlatego zwracam uwagę na nieco inne cechy systemu pakietów, niż
większość jego użytkowników.
>> Słabo natomiast znam apt. Dzisiaj na 7thguardzie pojawił się jednak
>> artykuł, który dale mi nadzieję: http://7thguard.net/news.php?id=4737,
>> akapit zatytułowany "Lokalne utrzymanie zmian w pakietach Debianowych."
>
> Ha, no tego nie znałem. Dzięki!
Nie ma za co. Jeśli tego da się rzeczywiście używać to po wyjściu Etcha
dam szansę jakiejś dystrybucji kierowanej przez kogoś innego niż ja.
Jeślibym zainstalował Debiana "testing", to tam pakiety będą już
nastawione na utf-8?
--
Jakub Panachida
dawid gajownik
> Dodatkowo ja buduję pakiety jedynie z gtk+2, a Debian z gtk+1, a
> rozbieżności jest więcej.
Zawsze można próbować zgłaszać błędy lub naskrobać coś na debian-devel ;)
Przykładowo, jakiś czas temu w Fedorze wprowadzono zasadę, by wszystko co
można kompilować z obsługą GTK2 (np. ethereal), a nie GTK1. Może by tak
zaproponować podobne rozwiązanie deweloperom Debiana?
(akurat piszę o Fedorze, bo w miarę dobrze znam tę dystrybucję)
> A tak przy okazji -- skąd masz wersję 4.4.2?
Z Rawhide'a (rozwojowej wersji FC). W FC4 jest 4.4.1
> http://rpm.org/ podają jako najnowszą wersję 4.2.
Ta strona jest chyba od dawna nieaktualizowana. Z tego co znalazłem w
pliku spec, to paczki brane są stąd → ftp://wraptastic.org/pub/rpm-4.4.x
Akurat w tej chwili nie mogę się połączyć, ale ten serwer ma taki sam nr
IP jak jbj.org, czyli serwer Jeffa Johnsona - dewelopera RPM.
> Jeślibym zainstalował Debiana "testing", to tam pakiety będą już
> nastawione na utf-8?
Nie mam niestety zielonego pojęcia :( Ledwo mi czasu starcza na używanie
FC4, testowanie Rawhide'a oraz zabawę z modularnym X.org X11R7. O innych
dystrybucjach wiem tylko tyle, co przeczytam na osnews.com,
7thguard.net czy linuxnews.pl :P
Hoppke
has been fingerprinted by dawid gajownik:
> Zawsze można próbować zgłaszać błędy lub naskrobać coś na
> debian-devel ;)
Prędzej chyba namówisz Billa żeby wypuścił Windows na licencji BSD... ;)
> Przykładowo, jakiś czas temu w Fedorze wprowadzono
> zasadę, by wszystko co można kompilować z obsługą GTK2 (np.
> ethereal), a nie GTK1. Może by tak zaproponować podobne rozwiązanie
> deweloperom Debiana?
Powiedzą, że gtk2 (lub wersja programu na gtk2) jest niestabilne/za mało
przetestowane i dlatego trzymają się gtk1. Serio.
dawid gajownik
> Powiedzą, że gtk2 (lub wersja programu na gtk2) jest niestabilne/za mało
> przetestowane i dlatego trzymają się gtk1. Serio.
Uuu... nie wiedziałem, że jest aż tak źle :( Wydawało mi się, że po
wydaniu Sarge będą bardziej postępowi. Szkoda.
Hoppke
has been fingerprinted by dawid gajownik:
>> Powiedzą, że gtk2 (lub wersja programu na gtk2) jest niestabilne/za
>> mało przetestowane i dlatego trzymają się gtk1. Serio.
>
> Uuu... nie wiedziałem, że jest aż tak źle :( Wydawało mi się, że po
> wydaniu Sarge będą bardziej postępowi. Szkoda.
Nie, polityka Debiana się nie zmieniła. Sarge nie jest żadnym przełomem
czy rewolucją, to część normalnego rozwoju debiana i pokazuje, że
mają swój plan i konsekwentnie go realizują.
Dla ludzi potrzebujących w miarę współczesnego (z poślizgiem do 6 m-cy)
biurkowego oprogramowania jest Ubuntu, dla potrzebujących naprawdę
aktualnego oprogramowania są jeszcze inne dystrybucje... debian nie
może być "aktualny" z definicji, bo Debianowcy (często całkiem słusznie)
uważają, że aktualność to równocześnie niestabilność. I że
przetestowany, pewny może być tylko przykurzony software grubo
podsmarowany patchami.
OTOH, jadę na cookerze Mandrivy, oni tam mają X.org z CVS i... nic mi
się nie zawiesza czy nie wywala. No ale Mandriva nie porywa
się na równoległe supportowanie 11 architektur itp. rzeczy które w
Debianie zżerają niesamowite ilości energii.