jaka nazwa w pkgssel

[Paweł Kołodziej]

[piątek, 21 maj 1999], Paweł Gajda napisał(a):

> On Fri, 21 May 1999, Paweł Kołodziej wrote:
> 
> > [czwartek, 20 maj 1999], Jarek Woloszyn napisał(a):
> > 
> > > On Thu, 20 May 1999, Paweł Gajda wrote: 
> > > 
> > > > 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).
> > 
> > Z moich obserwacji wynika, że w nagłówku 50% to spis nazw plików, a 20% to
> > description. O ile description nie odgrywa żadnej roli w sprawzaniu
> > zależności, to AFAIK spis plików jest już konieczny. Tak więc ewentualny
> > zysk na pamięciożerności to ok. 20% - IMHO trzeba się zastoanowić, czy warto
> > się teraz bawić w db. Może najpierw zróbmy wersję 1.0, możliwie najprostszą
> > ?
> 
> Teraz, czy później... Rozumiem, że narzekasz na brak czasu.  IMHO

na poniedziałek muszę sobie opracować ponad 100 temattów na ustny polski.

> przydałby się po prostu ktoś do tego indeksu.

Dobra, zrobię to. Przejrzałem info od db i wydaje mi się, że będzie to
raczej proste. Mysłę że mogę obiecać, że pojawi się to w sobotę (29.05) po
południu, albo wcześniej. A widzę to jakoś tak:
będzie sobie funkcja w rpmmen.c :
void * rpmpkgs_get_header_entry(TPkgSet *pkgs,int num, int item); 
która będzie zwracała wskaźnik na odpowiednie pole nagłówka, lub daną
pobraną przez db, albo NULL'a w przypadku błędu. Gdy ta dana przestanie być
już potrzebna będzie trzeba użyć:
rpmpkgs_free_entry(void *ptr);
gdzie ptr to wskaźnik który otrzymano od rpmpkgs_get_header_entry. Nie można
zamiast tego zrobić poprostu free, bo jeśli otrzymana "informacja" pochodzi
na nagłówka (tocfile) a nie z db to wtedy niewolno dealllokować tej pamięci.
Dopóki tego niema, do testów Jarek może używać atrap (rpmpkgs_get... taka
jak podałęm w poprzednim liście, a jako rpmpkgs_free_entry funkcji pustej).

Kilka luźnych uwag:
- otrzymany wskaźnik wskazuje na pamięć którą trzeba traktować jako ReadOnly
- w najbliższym czasie przejdę z *packages na **packages, ale zmiany w
  selekcjonerze z tym związane nie powinny być zbyt dokuczliwe.

> Zmontuję jednak jakiś kawałek
> strony, trzeba nasilić akcję propagandową ;-)
> 
> To po usunięciu tagów:
>     RPMTAG_DESCRIPTION,
>     RPMTAG_SUMMARY,
>     RPMTAG_BUILDTIME,
>     RPMTAG_BUILDHOST, 
>     RPMTAG_COPYRIGHT,
>     RPMTAG_GROUP,
>     RPMTAG_URL,
>     RPMTAG_PACKAGER,
>     100,           -- tajemnicze ,,znaczniki'' tłumaczeń  
>     RPMTAG_SOURCERPM,
>     RPMTAG_ARCHIVESIZE,
>     RPMTAG_FILEMODES,
>     RPMTAG_SIZE,
> 
> i nie dokładaniu niepotrzebnego tagu FILENAME_TAG, jest
> to przecież: %NAME-%VERSION-%RELEASE.%ARCH.rpm, AFAIK    

to jest już niewykożystywane. Kiedyś tego chyba potzrebowałem, ale już nawet
nie pamiętam do czego..

> W PLD będzie to większy zysk(dochodzą polskie(i węgierskie chyba też
> widziałem) wersje Summary i Description), ale nie wiem czy nie dojdą
> jakieś nowe i konieczne tagi w rpm-3.x.

Czy ktoś próbował już na rpm-3.x przekompilować rpmmen'a ?
Ja go jeszcze nie mam, i pocieszm się że może niechciało im się mocno
przerabiać "właściwego" rpm i API rpmliba pozostało w miarę niezmienione.


PS. a teraz wracam do świata Kochanowskiego, Mickiewicza, Asnyka i innych
Witkacych...

-- 
Paweł Kołodziej
pawelk w pld.org.pl
http://www.ids.pl/~pkollegu  <- tu jest PePeSza (automat dla tłumaczy .pot'ow)