różnice między APT a poldkiem

[Tomasz Kłoczko]

On Tue, 2 Jul 2002, Artur Frysiak wrote:

> On Tue, Jul 02, 2002 at 11:06:46AM +0200, Tomasz Kłoczko wrote:
> > On Tue, 2 Jul 2002, Artur Frysiak wrote:
> 
> > > Kolejny problem który rozwiązuje XMLowy format to wyraźne zakończenie
> > > poszczególnych sekcji. Swego czasu umieściłem komentarz w %post tyle, że
> > > %post był wykonywany nie przez /bin/sh a przez inny interpreter co
> > > spowodował, że linie zaczynające się od # były traktowane jako błąd. W
> > > przypadku XMLa wsadziłbym komentarz w <!-- --> i nie byłby on podawany
> > > interpreterowi %post do parsowania.
> > 
> > Jakbyś nie wiedział to od tego jest %{nil}.
> 
> Tzn ? Jak mam użyć %{nil} aby móc wstawić komentarz w dowolnym miejscu
> speca ?

%post 
ecie
pecie
%{nil}
# kometarz
# dwulininkowy
%postun
pecie
ecie
%{nil}
# inny kometarz

> > > Sprawdzanie poprawności składni pliku spec w XMLu jest o niebo
> > > łatwiejsze niż ma to miejsce aktualnie.
> > 
> > Co nie zmaczy że nie jest to wykonalne. Co więcej owo sparwdznie jest już
> > zaimplementowane i nawet działa :)
> 
> Gdzie jest zaimplementowane ?

W rpm-ie.

> > > Wyciąganie informacji z XMLa jest także dużo łatwiejsze.
> > 
> > Na razie nie jest w żaden sposób łatwiejsze niż obecnie.
> > %dump macro & grep/awk/perl rulez. Dokłądnie pzrecież tak robimy w 
> > builderze. Używanie do takich zreczy kilku narzędzie nei jest w żaden 
> > sposób niczym brzydkim. Więcej .. to jest zgodne z filozofią unices.
> 
> Ta, trick z %dump sam wymyśliłem ale jest to bardzo ugly trick i
> wolałbym aby go zarzucić.

Na rzecz czego ? Masz jakiś zewnętrzny parser ? Zresztakby nawet był to 
IMHO nie należałonby tego zmieniać bo to dokładnie nic by nei zmieniło. W 
ttej chwili całość jest prosta: wrzyca się całego dumpa do zmiennej a 
potem wyciaga co trzeba. Prościej zrobić to byłoby ciężko.

> > > Pliki XML są najczęściej kodowane w UTF-8 co rozwiązuje problem z
> > > tłumaczeniami w różnych językach.
> > 
> > Używanie utf w rpm-ie już obecnie nie ma w zasadzie ograniczeń już
> > obecnie. Pzrerób tylko programy które beą wyciagać z bazy rpm-a infrmacje 
> > i beą odpowienie tksty raktować jako utf.
> 
> Wyciąganiem informacji z bazy rpma powinno zajmować się librpm, a aby
> informacje z bazy mogły być traktowane jako utf to trzeba i tak API
> zmienić.

Nie widze tego gdzie byłoby to potrzebne.
Łańcuchy jakie są obecnei w Summary czy %description możesz i już wrzucać 
w utf i nie powinno to w niczym przeszkadzać.
Kwestia że np. programy to wyświetlajace pownny to traktować jako utf .. i 
to wszystko.

> > > Zastosowanie XMLa drastycznie zmiejszy "poprawki" typu "cosmetics".
> > 
> > Formatować plik xml-owy żeby się go czytało i tak się będzie. Popatrz ile
> > tego typu poprawek jest choćby w LDP.
> 
> Od tego są programy normalizujące pliki XML np. xmllint, który dodatkowo
> sprawdzi składnie pliku.

Walidacja jest elementem parsowania. To że do XML są gotowe zewnętrzne 
validatory nic tu istotnego nei zmienia, a to że Jeff nie zabrał się od 
początku za robienie parsera na yacc i postanowił robioć to na własna rękę 
o ile to dziąła takze nic tu istotnego nie wprowadza moze po za tym, że 
gdyby robił to z użyciem yacc to miałby prostzre rozwijanie składni.

> Używanie tego typu narzędzi jest mniej
> kontrowersyjne niż poprawka polegająca na usunięciu lub dodaniu pustej
> linijki lub też złamaniu linijki w tym a nie innym miejscu.

Tak długo jak to dział owa kontrwersyjność szczerze mówiac mnie ni grzeje 
ni ziębi, a wprowadzanie XML tylko dlatego zeby to "upiękkszyć" od strrony 
parsowanai jest głupim podejsciem bo nie uwzględnai tego kto bedzie potem 
tego używał.

> Mówiąc wprost uważam, że Twoje "cosmetics" to tylko szum informacyjny
> mający na celu zwiększenie liczby commitów i postrzeganie Twojej osoby
> jako superbossa analizującego wszystkie spece.

Czyżbyć i Ty najwidoczniej zaczynał mieć na tym punkcie jakieś kompleksy ?

> Szkoda tylko, że na specach to się kończy a nie idzie dalej w kierunku
> analizy wyników powstających z tych speców.

Szkoda w takim razie że nie robisz tego o czym mówisz. Mi to na razie nie
jest potrzebne, a i nie wiem czy mam pewność o czym piszesz.

> > > Zastosowanie XMLa pozwoli na opisanie alternatywnych położeń źródeł,
> > > pozwala na umieszczenie sumy md5 źródeł od razu w specu dzięki czemu
> > > weryfikacja integralności źródeł jest łatwiejsza.
> > 
> > Opisałem na rpm-list jak to rozwiązać bez uzywania XML-a. Mżan to zrobić 
> > skryptem ala builder + baza translacji adresów (i tak używajac XML 
> > będziesz musiał także używac takiej bazy).
> 
> Ta, tyle że wtedy potrzebuje spec, skrypt i bazę. O rozjechanie się
> takiej konstrukcji  bardzo łatwo. Wole mieć spójne dane w jednym pliku.

W przypadku XML będziesz miał: spece w XML, kawałek skrypru i bazę 
translacji URLi. Aż tak mocno się to różni ? :)

> > Wszystko co podałeś to są pewne argumety ale ich wielkość jest taka że
> > potknąć sie o nie jest naprawdę cieżko.
> > 
> > Używanei XML nie uwzględnia jedenego fundamentalnego faktu. Otóż rpm to
> > narzędzie które ma już ca~ siedem lat z okładem. Przez ten czas
> > powstała grupa ludzi która ma to co jest obecnie w małym palcu lewej
> > stopy. Obecnie jest takzę sporo dobzre opracowanych specół 
> > (choby u nas) i jak an razie nei ma prostych narzędzie do 
> > migracji do XML. Wprwadzenie XML tutaj dla tych ludzi wprowadzi wiąze się
> > z takim zamieszaniem że głowa mała. Owszem wsprowadzenie XML ma senss od
> > strony Jeffa (uproszczenie parsowania) ale on jest jeden na osób robiących
> > pakiety tysiące.
> 
> To jest typowo konserwatywny argument osoby, której nie chce się już
> dalej rozwijać i obawiającej się, że nowa technologia strąci ją z
> piedestału.
> Jakoś mi to do Ciebie, Tomku nie pasuje. Zawsze podziwiałem Twoje
> ciągotki do nowych rzeczy. No ale tylko krowa nie zmienia poglądów.

Artur może na pczątek zacznij ulepszać np. awka ? a może sh ? :>
Istotą czegoś co jest dobre jest to że na pewnym poziomie nie trzeba tego
zmieniać bo tworzy to pewną spójna platformę do dalszych działań. Taka
platforma istnieje o czczym świadczy to że my sami wykonujemy na specach
operacje które innym ludziom w głowie nie za bardzo się mieszczą (vide 
dyskusja na rpm-list że bez XML inaczej pewnych rzeczy sie nie da zrobić). 
To że ktoś czegoś takiego nei potrafiłby zrobić bez XML jest tylko
ograniczeniem konkretnej osoby a nie tego co obecny rpm jako platforma
udostępnia. Nie moje to zmartwienie kto jakie ograniczenia sam sobei na
siebie ponakładał.

> > Na rpm-list pisałem także że jeżeli ktoś chce koneicznie używać 
> > XML-a to mozę to robić juz teraz. Wystarczy że napisze sobei dopowiedni 
> > arkusz XSLT którym bezie renderował speca w XML do obecnej formy.
> > Nikt nic w ten sposób nie straci, a osoby które chcą wprowadzć XMl 
> > wszedzie gzdie sie da bbędą także zadowolone.
> 
> Owszem jest to możliwe. Możliwe będzie także używanie starego formatu
> plików spec z rpmem 4.1. Jeff na rpm-list napisał, że stary format pliku
> spec pozostanie jeszcze bardzo długo a może nawet na zawsze.

I bardzo ładnie z jego strony.
Przypomnę tylko słowa choćby Linusa że jeżeli masz coś zrobić nie rób to 
na kilka sposóbów bo żaden nie będzie dobry.
  
> > Inne bajki jak wprowadzenie opisu pakietów neizależnych od dystrybucji 
> > także właozyłbym między bajki. To się nie da zrobić bo wtedy by to 
> > znaczyło że nie ma sensu robić różnych dystrybucji i że tego typu zajęcia 
> > nie mają racji bytu co jest, a przynajmniej bezie jeszcze pzrez długi
> > czas oczywistą bzdurą.
> 
> A mnie męczy gdy chcąc pomóc developerom jakiegoś projektu i dostarczyć
> im plik spec musze robić kombinacje aplejskie aby spec był użyteczny
> przynajmniej w kilku dystrybucjach.
> Może upowszechnienie LSB i Unilinux coś zmieni w tej sprawie.

To jest typwy błąd. Ten sam bład w podejśsciu widzę w u obecnych naszych
TeXowców. Koniecznie chcą uszczęśliwić twórców dystrybucji i chcą zrobić
włąsny (jeszcze jeden) opisu pakietów TeXowych co umożliwiłoby zapakowanie
tego w dowolną dystrybucję. Nie rozumieją, że zadaniem osób
opracowujących projekt jest dobzre ten projekt rozwijać .. poprstu.
Obecne prace nad owym "standardem" są taka utajnione ze nawet rozmowa na 
ten temat jest z lekak nie wskazana (tu piję akurat wprost do Krzysia).

Poropstu ludzi zajmujący sie poszczególnymi prjektami nie powinni się pod
żadnym pozorem martwić o to jak to potem to zapakować. To jest zadanie
ludzi robioacych dystrybucję i platforma jaka udosepnai przyokładowo ac/am
jest w stu procentach wystarczajaca do tego żeby to ładnie zrealizować nie
klnąć przy tym na nikogo.
Przykład podałem na rpm-list że yto nei ma sensu: w wielu pakeitach są 
spece juz nei tyle naewet pod dowolna dystrybucje co specjalnei pod RH 
których to sopeców nawet RH nie chce używać.

Co do TeXowców to "wrórze" że z tego co robia wyjdzie taki potworek że
nikt tego nie będzie chciał uzywać. Czyli że pójdzie tona czaqsu w
gwizdek, a dodatkowo ludzi którzy znaja się na typografii zawalą jakiś
kawałek czegoś i za kałałek pytanie o TeXa bęzie juz naprawdę bardzo
dziwnie brzemieć.

> > I jeszcze jedno. Na rpm-list pojawiły sie przy okazji dyskusji próbki 
> > prezentacji specół jak by mogły wyglądac w XML. Pierwsze co sie rzuca w 
> > oczy że to to ze takie spec jest około 2.5 raza dłuzszy od obecnej 
> > postaci. Jest przy tyum mniej czytelny. by osiągnać odpowidni poziom 
> > czytelnosci informacji w nim zawartych ztreba bedzie uzywać jakiś nakładak 
> > które beą to prezekntować choćby .. w postaci onbecnej formy speca albo 
> > inej on markapowionej postaci (można do tego celu użyć choćby emaca ale 
> > wybacz .. używanie do tego tego typu kobyły żeby poprawić kila drobiazgów
> > to jednak kiepski pomysł).
> 
> Niech sobie będzie i 5 razy dłuższe o ile rozwiąże to problemy o których
> pisałem.

Patrz zdanie na końcu tego listu.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*