Zmiany w obsłudze pakietów architektury all w repozytorium Debiana
- Dodano: 18 listopada 2009
- Wprowadził: azhag
- Komentarze: 6
Torsten Werner zdradził na blogu szczegóły na temat zamykania błędu #246992, który dotyczy obsługi pakietów architektury all w archiwum Debiana. Dzięki jego pracy, różne wersje pakietów przeznaczone dla każdej architektury będą zachowywane w repozytorium tak długo, jak będą ich wymagały inne pakiety. To oznacza, że w przyszłości powinny zniknąć problemy z zależnościami pakietów w gałęzi niestabilnej.
Werner zastąpił stary skrypt make_suite_file_list.py w narzędziu dak, który jest używany do obsługi archiwum Debiana, dwoma nowymi: generate_filelist.py oraz dominate.py. Pierwszy z nich tworzy listy plików dla apt-ftparchive, drugi usuwa stare pakiety z bazy danych.
Kod napisany przez Torstena Wernera został już dołączony do narzędzia dak, wkrótce zacznie być używany na ftp-master.debian.org. Nie może ponownie dodać pakietów, które zostały już usunięte, ale dzięki niemu w przyszłości archiwum będzie bardziej przyjazne. Niestety pozostawiać będzie więcej śmieci w repozytorium. Grupa FTPMaster prosi o pomoc w śledzeniu taki przypadków — błędy w archiwum powinny być zgłaszane jako dotyczące wirtualnego pakietu ftp.debian.org.
Główna funkcja w stary skrypcie make_suite_file_list.py posiadała uroczą nazwę do_da_do_da(). Jedna z funkcji nowego skryptu dominate.py otrzymała nazwę doDaDoDa(), jako pamiątkę po autorach starego kodu, którzy nie są już członkami grupy FTPTeam.
Więcej informacji na temat obsługi pakietów architektury all można znaleźć na wiki grupy FTPTeam.
Więcej informacji: http://dug.net.pl/news/34
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
6 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
A już myślałem, że przechodzą na RPMy
Hehe, wcale nie oznacza to, ze przyszlosci znikna problemy z zaleznosciami w sidzie. Ciagle zdarzaja sie rozjazdy pomiedzy czesciami tej samej aplikacji (np. costam-common i costam-gtk sa w roznych wersjach) oraz w zaleznosciach bibliotek (wymaga lib 1.2.3, ale lib 1.2.3.1 jest zainstalowane)
Problem wynika właśnie z obsługi pakietów *_all.deb. Na przykładzie:
W repozytorium znajduje się program <code>foo</code> w wersji 1. Pakiet podzielony jest na binarkę dla poszczególnych architektur oraz pliki wspólne: <code>foo_1_i386.deb</code>, <code>foo_1_amd64.deb</code> i <code>foo-common_1_all.deb</code>. Nagle wychodzi nowa wersja i zaczyna się budowanie pakietów dla poszczególnych architektur, z różnych powodów (FTBFS, buildd nie wyrabia, pełnia księżyca) nie dla wszystkich architektur pakiet zostaje zbudowany — w przykładzie zostaje zbudowany dla amd64, dla i386 nie.
Mamy teraz pakiety: <code>foo_1_i386.deb</code>, <code>foo-common_1_all.deb</code>, <code>foo_2_amd64.deb</code> i <code>foo-common_2_all.deb</code>. I przechodzimy do sedna: dotychczas pakiet <code>foo-common_1_all.deb</code> jest usuwany, ponieważ zostaje zastąpiony nowszą wersją — <code>foo-common_2_all.deb</code>, co psuje zależności w architekturze i386.
W modelu, który wkrótce wejdzie w życie pakiet <code>foo-common_1_all.deb</code> będzie trzymany tak długo, jak w repozytorium będą występowały <code>foo_1_„any”.deb</code>.
Problemy (no, większość) wynikają właśnie z przesunięcia budowania pakietów dla różnych architektur i dość rygorystycznym zastępowaniu pakietów dla all przez nowsze wersje.
PLD ma to rozwiazane jako pakiety costam-wersja-noarch.rpm wczesniej
przed wyslaniem takiego pakietu automat sprawdza czy wszystkie buildery (z roznych arch) stworzyly paczki z taka sama zawartoscia jesli nie -> mail do wysylajacego zlecenie.
Powodzenia
Długo trzeba będzie czekać na wprowadzenie jądra 2.6.31 do Debiana squeeze?
A gdzie te dodatkowe informacje na stronie wskazywanej przez link w polu "Więcej informacji"?
Złożyłem propozycję na sugesterze, aby poprawić niezdrową sytuację na OSnews.pl.