SPECS: tcl.spec (HEAD)
Jacek Konieczny
jajcus w bnet.pl
Śro, 31 Gru 2003, 09:46:23 CET
On Tue, Dec 30, 2003 at 10:39:36PM +0100, Jakub Bogusz wrote:
> On Tue, Dec 30, 2003 at 09:08:05PM +0100, jajcus wrote:
> > Module name: SPECS
> > Changes by: jajcus 03/12/30 21:08:03
> >
> > Modified files:
> > tcl.spec
> >
> > Log message:
> > - include both %{_libdir} and %{_ulibdir} in PACKAGE_PATH so platform-dependant tcl packages could be loaded properly on AMD64
>
> Tu raczej %ifarch jest potrzebne - bo będą duplikaty na innych
> architekturach.
Z tego co widziałem, to tcl sam się duplikatów pozbywa (przynajmniej jak
łączy listy katalogów z różnych źródeł). Ale trzebaby to sprawdzić, albo
rzeczywiście %ifarch zrobić.
No i podobny problem pojawia się w przypadku wszystkich języków
skryptowych. Mają one zwykle swoje moduły w %{_libdir}. Zarówno te
niezależne od architektury jak i te zależne. Póki %{_libdir} to było
zawsze /usr/lib to nie był taki problem (poza lekkim nagięciem FHS),
gdy %{_libdir} jest /usr/lib64 to się problem zaczyna:
Jeżeli pakiet z modułem do języka jest noarch, to wcale taki noarch nie
będzie, bo zależnie na jakiej architekturze się zbuduje, to wyląduje w
/usr/lib, albo /usr/lib64. Wrzucić wszystkiego do /usr/lib na sztywno
też za bardzo nie można, bo utrudni to jednoczesne instalowanie modułów
32- i 64-biotwych na architekturach na których to możliwe.
Chyba wszystkie ważne języki (tcl, python, perl) mają teraz możliwość
rozdzielenia katalogów na pakiety zależnych i niezależnych od
architektury. Więc można by tego użyć to rozdziału /usr/lib, /usr/lib64,
ale w takim razie czemu nie od razu /usr/share i %{_libdir} -
tylko że to byłaby zbyt duża zmiana w całym PLD.
W przypadku Tcl wydaje się, że ta prosta zmiana w tcl.spec powinna
ułatwić rozdzielanie wszystkich tclowych pakietów.
Na razie mam problem: co ładować do %{_libdir}, a co na sztywno do
/usr/lib. I na razie kieruję się tylko tym czy się wszystko buduje
- jak będziemy mieli komplet pakietów dla buildera będzie to wszystko
można poprawiac w ramach "normalnego rozwoju PLD".
Pozdrowienia,
Jacek
Więcej informacji o liście dyskusyjnej pld-devel-pl