Budowanie zale?nych od siebie pakiet?w (Re: 2.2 vs 2.4 -- propozycja)

Arkadiusz Miskiewicz misiek w pld.ORG.PL
Wto, 24 Lip 2001, 01:03:13 CEST


Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> writes:

> > kloczek daruj sobie!
> > Nie zauważyłeś, że tu NIKOMU poza tobą się ta propozycja nie podoba? 
> 
> Zauwazyłem także, że nikt nie protestuje przeciwko pcmcia-cs w
> kernelu.  
Ja Ci wytłumacze dlaczego tak jest. Bo to najwyraźniej nikomu nie
przeszkadza.

> Zauważyłem takze, że zabieraja w tej rozmowie głos osoby które nie będą
> narażone na negatywne skutki takiej zmiany (bo same jeszcze nei miały
> potrzeby grzebania w zasonbach około kernelowych i wręcz pzreciwnie ..  
> potencjalnie skorzystają na tym). 
No to ja należę do osób, które grzebały w okernelowych pakietach i nie
chcą tych ,,negatywnych skutków takiej zmiany'' bo zyski to NIC w
porównaniu z NEGATYWNYMI skutkami.

> zauważasz tego, że po takiej zmianie bałagan z niespójnością zasobów
> modułów zniknie raz na zawsze.
A spójność zasobów mi wisi bo to akurat o wiele mniejszy problem niż
rekompilacja bydlastego kernela.

> Zauważam także to że sprawa nie dotyczy MNIE tylko konkretnych
> zasobów.
Ale tylko TY masz z tym problem. Kto się z Tobą zgodził? KTO? Nikt.

> Widzisz mam można powiedzieć głupią cechę. Jestem uparty o ile ile nie ma
> konkretncyh *kontrargumentów* obalajacych to co zauważam.
Czyli to, że ,,bałagan z niespójnością zasobów modułów zniknie raz na
zawsze''? Nikt temu nie zaprzecza. Niespójność by znikła ale za to
pojawiły by się takie problemy jak:
1) przerąbane maintainowanie kernelem i składnikami z jakich się składa
(niemożność przetestowania zmian ze względu na to, że to było by
dopiero ogromne bydle i się długo kompiluje, zmiany w interfejsach,...)
2) niemożnośc używania własnych kerneli (a to już jest taki argument,
którego mocno nie nadgryziesz), a co za tym idzie:
3) niemożność kompilowania poszczególnych części takich jak lirc, alsa
itd
4) udręka dla modemowców (po to by zrobić sobie rpma z lircem czy alsa
trzeba by ściągać źródła _całego_ kernela). 

Pewnie jeszcze pojawi się kilka kontrargumentów, a te które już są
_pojedyńczo_ biją na głowe argument dot. spójności zasobów.

> W tym sensie
> jestem niesamowicie zdaje sobie że niemożlność wysuniecia takich
> kontrargumentów z powodów czysto emocjonalnych moze być niewygodna. I
> tylko nie pisz że jestem nieprzekonywalny. Jezli wykażesz miwykłądając
> fakty że się mylę to z zawsze to przyjmuje ze spokojem.
To jest raczej tak, że słyszysz ale nie słuchasz.

> Na ftp leży pojad 2.5K pakietów per arch. Sprawa w tej chwili dotyczy 
> (słownie) dziesieciu pakietów (6 sztuk kernel, 2 alasa, 1 svgalib, i 
> masq). 
Aha, to znaczy, że o lirc, openafs (bydle kolejne), nvidia się nie
liczą? Zapewne o nich zapomniałeś. Teraz do tego dojdzie kolejne kilka
pakietów których w PLD jeszcze nie mamy ale możemy mieć. Napisz sobie
jakiś skrypt do trzymania tego w kupie, a nie mącisz.

> Wybasz ale jakby nie patrzęć to nie jest cała dystrybucja (nawet 
> nie jej jeden procent).
To jest jeden z ważniejszych elementów dystrybucji (np. obraz i dzwięk)

> Po drugie nie jest to moja idea. Jest to *czyste rozwiniecie* tego co 
> Janek kiedyś zrobił i co *do dzisiaj się dobrze sprawsdza* (nikt nie
> narzeka że ma noduły do pcmcia-cs nie od tej wersji kernela jaka leży na 
> ftp). Sam to w pierszym monecie przyjałem nieco kręcąc noasem ale skoro 
> już było to zrobione to sam w duchu zaakceprtowałem (wtedy jeszcze nie 
> miałem notebooka). Dzisiaj zauważam że ma to szerszy sens który moząń 
> rozwinać na resztę tego typu zasobów.
Plusy z zastosowania takiego rozwiązania są i każdy je widzi. Tylko że
większość z nas widzi również minusy podczas gdy Ty o nich
najwyraźniej zapominasz - DLACZEGO?. To jest rozwiązanie, które w
efekcie da więcej złego niż dobrego (o czym napisałem wyżej).

> Zauważ że to nie jest wyłącznie niczym nieuzasadniony upór ..
Tak sobie tłumacz.

> Błędem moim było w tym wypadku to że wciągnąłem się w dyskusję publicznie.
> Powinienem to skonsultować z przykładowo Jankiem i Arturem (czyli 
> osobami które wiedzą sporo o zasobach których dotyczy sprawa bo same
> brały aktywny udział w ich preparowaniu czyli kernel i alsa) i co
> najwyżej tylko te osoby przekonywać. W sytuacji kiedy miałbym 
> dgotową poprawke (której sporządzenie zajełoby mi mniej czasu niż ta cała
> dyskusja) przekonywać mógłbym żywym zasobem (byłoby to juz bardzo
> łatwe).
To chyba już zapomniałeś jak to było z Wojtkiem
Ślusarczykiem. Najpierw były commitowane łatki, a potem wielka
dyskusja, że to źle, bez dyskusji, SbO itd. 

> W tym sensie jest to też nauka dla innych jak nie próbować wprowadzać 
> pewnych zmian i/lub na co należy zwrócić uwagę podczas takich
> operacji.
Przyczepiłeś się tego niemożliwie. Zapomnij o forsowaniu czegokolwiek
czego nie chce przynajmniej część developerów (którzy wiedzą co mówią). To nie
jest tak, że sobie wymyślamy coś ot ,,bo tak''. Mamy konkretne
argumenty, które Ty ignorujesz albo stwierdzasz, że nie są warte funta
kłaków i nadal wałkujesz swoje.

I wyzbyj się w końcu załawiania wszystkiego po kryjomu, wprowadzania
zmian licząc na to, że nie będzie odwrotu (piszę tu w kontekście
,,nauki ... jak nie próbować wprowadzać ... zmian'').

> kloczek

Jeszcze raz powtarzam - zapomnij o forsowaniu tego na siłę! To, że
przygotujesz sobie zmianę, commitniesz i postawisz nas przed faktem
dokonanym to będzie z Twojej strony po prostu - *delikatnie mówiąc* -
nieładnie.

-- 
 Arkadiusz Miśkiewicz, AM2-6BONE, 1024/3DB19BBD
 IPv6 ready PLD Linux at http://www.pld.org.pl/
My jsme Borg. Odpor je marný, budete asimilováni



Więcej informacji o liście dyskusyjnej pld-devel-pl