jaka nazwa w pkgssel

[Paweł Gajda]

On Wed, 19 May 1999, Jarek Woloszyn wrote:

> On Wed, 19 May 1999, Paweł Gajda wrote:
> 
[..]
> > Na dobrą sprawę to należałoby wziąć jeszcze pod uwagę wersję
> > pakietu. Chyba najlepiej nie kombinować i brać tę największą, 
> > a resztę odrzucać.
> 
> Tylko, ze moga byc tez problemy z zaleznosciami :) Ale na moj prosty rozum
> pakiety w kilku wersjach beda raczej te ostateczne, tzn. ktore raczej nie
> beda nic providowaly (ach ten polski jezyk :)

? Powyższego nijak nie rozumiem ;-(


[..]
> 
> > W zależności od sposobu realizacji zaznaczeń w rpmenie(nie do końca
> > wiem, jak to jest zrobione): 
> > - lista ,,instalacyjna'' będzie musiała zawierać nr wersji
> > - jeżeli zaznaczamy pakiet przez wskazanie *rekordu*(np. przez indeks
> >   lub wskaźnik), to nr wersji nie będzie potrzebny.   
> 
> Nie za bardzo lapie o co ci chodzi w tym drugim myslniku. Z tego co zrobil
> Pawel w 0.1 pkgsela wywnioskowalem, ze bedziemy mieli liste pakietow (ta
> cala struktura PkgSet) i tam jest pole selected, ktore przyjmie
> odpowiednia wartosc, po przepuszczeniu listy przez wybieraczke. Sam rpmmen
> sie martwi dalej o zaleznosci.

Czyli ten 2 przypadek, tak mętnie przeze mnie opisany :-) 


[..]
> > Jeżeli dobrze się domyślam(niechęć do wołania headerGetEntry()) to: 
> > 
> > Nagłówek jest już w strukturze, także, jeżeli zaznaczanie pakietu
> > odbywa się poprzez wskazanie rekordu, to IMHO lepiej opakować funkcję
> > headerGetEntry() w coś takiego: rpmpkg_header_entry_get(pkg*, entry).
> > Zaoszczędzimy te parę kB(co prawda, przy paru MB wymaganych przez 
> > rpmlib, ale zawsze :-).  
> 
> Cos takiego by bylo bardzo przydatne. Wtedy nie trzeba by bylo ciagle
> trzymac tej wersji w pamieci, tylko do pokazywania na ekran wolaloby sie
> to rpmpkg_header_entry_get i po sprawie.

To mała rzecz, może po prostu dorób to sobie? Nie wiem czy Paweł 
znajdzie czas.         


> 
> > Tak na marginesie, to trzymanie nagłówków tych >500 pakietów będzie b.
> > pamięciożerne. Niestety nie ma sposobu obejścia tego, rpmlib wymaga
> > podania listy nagłówków przy wynajdowaniu zależności(lista siedzi w
> > pamięci). Może jest ktoś chętny do poprawienia rpmliba? :-)
> 
> W sumie to najwiecej zajmuja opisy. Nie wiem jak jest robiony tocfile i
> czy naglowki maja stalo dlugosc. Jesli nie, to na poczatku tocfile trzeba
> by zrobic jakis index z opisem w ktorym miejscu sa kolejno (wg. numerow)
> pakiety. Potem do pamieci ladowac tylko to co potrzebne (bez opisow).
> Opisy pokazywane sa tylko w wybieraczce, wiec moglaby byc funkcja, ktora
> otwiera toca, skacze w odpowiednie miejsce (zaleznie od numeru pakietu) i
> zwraca opis. Nie wiem jak dokladnie dziala rpmlib, wiec to tylko suche
> pomysly.

Dobre! Sprawdziłem, po wyrzuceniu Description, Summary, Copyright itp,
plik zmniejsza się średnio o połowę(570 pakietów z RH5.2). 

W postaci, którą zaproponowałeś, to raczej będzie nieefektywnie
(ze względu na budowę rpm headera - AFAIK trzeba czytać go w całości).
IMHO najlepiej to rozbić na 2 pliki: tocfile okrojony do minimum, 
i descriptions w postaci pliku db ,,juzerskimi'' informacjami. 
Zamiast samemu budować indeks, można to wrzucić do pliku db(libdb).
Oczywiście trzeba to opakować tak, żeby to było dla Ciebie 
przezroczyste, powiedzmy w moduł rpmheadinfo do rpmmenliba. 
Ktoś chętny(prooszę)? :-)

Paweł
-- 
mailto: mis w k2.net.pl