copyright © 1998—2003 Adam Di Carlo
copyright © 2002—2003 Raphaël Hertzog
copyright © 1997, 1998 Christian Schwarz
Niniejszy podręcznik jest wolnym oprogramowaniem; możesz go rozpowszechniać i/lub modyfikować na warunkach Powszechnej Licencji Publicznej GNU wydanej przez Fundację Wolnego Oprogramowania - według wersji 2-giej tej Licencji lub którejś z późniejszych.
Podręcznik ten rozpowszechniany jest z nadzieją, iż będzie on użyteczny, jednak bez jakiejkolwiek gwarancji; nawet domyślnej gwarancji przydatności handlowej lub przydatności do określonych zastosowań. W celu uzyskania bliższych informacji - patrz Powszechna Licencja Publiczna GNU.
Kopia Powszechnej Licencji Publicznej GNU dostępna jest jako
/usr/share/common-licenses/GPL w dystrybucji Debian GNU/Linux lub
w Internecie na stronie
GNU. Możesz otrzymać ją także pisząc na adres Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Polskie tłumaczenie ukazało się nakładem sił następujących osób z projektu
PDDP:
Tłumaczenie dostępne jest na tych samych zasadach co oryginał.
debian/rulesdebian/controldebian/changelogdebconfdebian/rulesdevscriptsautotools-devdpkg-repackaliendebsumsdpkg-dev-eldpkg-depcheckIntencją tego dokumentu jest dostarczenie informacji na temat zalecanych sposobów postępowania oraz dostępnych zasobów dla deweloperów Debiana.
Omówione tutaj procedury informują, jak zostać opiekunem pakietów (Zgłoszenie chęci zostania Opiekunem Debiana, Część 2), jak tworzyć nowe pakiety (Nowe pakiety, Rozdział 5.1) oraz jak je przesyłać (Umieszczanie pakietów w archiwum, Rozdział 5.6), jak radzić sobie z raportami o błędach (Obsługa błędów, Rozdział 5.8), jak przemieszczać, usuwać lub osierocać pakiety (Przenoszenie, zmiana nazwy, adopcja i osierocanie pakietów, Rozdział 5.9), jak przenosić pakiety na inne architektury (Przenoszenie na inne architektury, Rozdział 5.10) oraz jak i kiedy wykonywać tymczasowe wydania pakietów innych opiekunów (Przesyłanie pakietów przez nieoficjalnego opiekuna (Non-Maintainer Uploads (NMU)), Rozdział 5.11).
Omawiane w tym podręczniku zasoby obejmują listy dyskusyjne (Listy dyskusyjne, Rozdział 4.1) oraz serwery (Maszyny Debiana, Rozdział 4.4), strukturę archiwum Debiana (Archiwum Debiana, Rozdział 4.6), różne serwery akceptujące przesyłanie pakietów (Przesyłanie do ftp-master, Rozdział 5.6.1), a także zasoby, które mogą być pomocne opiekunom w utrzymywaniu pakietów na wysokim poziomie (Przegląd narzędzi opiekuna Debiana, Dodatek A).
Powinno być jasne, że podręcznik ten nie omawia technicznych szczegółów
dotyczących pakietów Debiana, nie mówi także jak tworzyć pakiety. Pomija
również szczegóły dotyczące standardów, jakie musi spełniać oprogramowanie
Debiana. Wszelkie tego typu informacje dostępne są w Podręczniku Polityki
Debiana.
Kontynuując, dokument ten, nie jest wyrazem oficjalnej polityki. Zawiera jednak informacje o systemie Debian i ogólnie przyjętej praktyce. Tak więc jest tym co nazywane jest ,,praktycznym'' dokumentem.
A więc przeczytałeś całą dokumentacje, przebrnąłeś przez podręcznik dla nowych opiekunów
pakietów Debiana, zrozumiałeś, do czego służy wszystko z
przykładowego pakietu hello, i zaraz zdebianizujesz swój ulubiony
program. Jak zostać rozwijającym Debiana, aby Twoja praca mogła zostać
włączona do Projektu?
Najpierw, jeśli jeszcze tego nie zrobiłeś, zapisz się na listę debian-devel@lists.debian.org.
Wyślij słowo subscribe w temacie wiadomości poczty
elektronicznej na adres debian-devel-REQUEST@lists.debian.org.
W razie kłopotów zgłoś się do administratora listy pod adresem listmaster@lists.debian.org.
Więcej informacji o listach dyskusyjnych znajdziesz w Listy dyskusyjne, Rozdział 4.1. debian-devel-announce@lists.debian.org
jest następną listą obowiązkową dla każdego, kto chce uczestniczyć w rozwijaniu
Debiana.
Powinieneś zapisać się na te listy i podglądać je (to znaczy czytać bez wysyłania wiadomości) przez jakiś czas przed rozpoczęciem pracy. Powinieneś także wysłać wiadomość na listę o Twoich zamiarach pracy nad czymś, aby dwie osoby nie robiły tego samego.
Inną dobrą listą do subskrypcji jest debian-mentors@lists.debian.org.
Aby dowiedzieć się więcej, zajrzyj do Mentorzy i sponsorzy
Debiana, Rozdział 2.3. Pomocny może być również kanał IRC
#debian.
Jeśli wiesz, jak chcesz przysłużyć się projektowi Debian GNU/Linux, powinieneś
skontaktować się z obecnymi opiekunami Debiana, którzy pracują przy podobnych
zadaniach. W ten sposób możesz uczyć się od doświadczonych rozwijających. Na
przykład, jeśli jesteś zainteresowany stworzeniem pakietu Debiana z
istniejącego oprogramowania, powinieneś spróbować znaleźć sponsora. Sponsor
będzie z Tobą pracował nad Twoim pakietem i wysyłał go do archiwum Debiana,
kiedy uzna, że praca, którą wykonałeś nad pakietem, jest zadowalająca. Możesz
znaleźć sponsora wysyłając wiadomość na listę dyskusyjną debian-mentors@lists.debian.org,
opisując swój pakiet, siebie i prosząc o sponsora (po więcej informacji o
sponsorowaniu zajrzyj do Sponsorowanie pakietów,
Rozdział 7.5.1). Z drugiej strony, jeśli jesteś zainteresowany
przeniesieniem Debiana na inne architektury lub jądra, możesz zapisać się na
listę dyskusyjną dotyczącą konkretnego portu i tam zapytać się, jak możesz
rozpocząć pracę. Na koniec, jeśli jesteś zainteresowany pisaniem dokumentacji
lub pracą w Zapewnianiu Jakości (Quality Assurance - QA), możesz dołączyć do
opiekunów, którzy już pracują nad tymi zadaniami i wysyłać im łatki i
usprawnienia.
Zanim zdecydujesz się na rejestrację w projekcie Debian GNU/Linux, musisz
przeczytać wszystkie informacje dostępne w Kąciku Nowych
Opiekunów. Opisane są tam dokładne przygotowania, które musisz
poczynić, abyś mógł zarejestrować się jako chętny do bycia rozwijającym
Debiana. Na przykład, przed złożeniem zgłoszenia musisz przeczytać Umowę Społeczną
Debiana. Zarejestrowanie się jako rozwijający oznacza zgodę i
przyrzeczenie, że będziesz przestrzegał zasad opisanych w Umowie Społecznej
Debiana (the Debian Social Contract). To bardzo ważne, aby opiekunowie
postępowali zgodnie z podstawowymi ideami stojącymi za projektem Debian
GNU/Linux. Dobrym pomysłem byłoby również przeczytanie Manifestu GNU.
Proces rejestracji dewelopera jest procesem weryfikacji Twojej tożsamości i intencji, a także sprawdzeniem Twoich umiejętności technicznych. Ponieważ ilość ludzi pracujących w projekcie Debian GNU/Linux zwiększyła się do ponad 800, a nasze systemy są używane w wielu bardzo ważnych miejscach, musimy uważać na wszelkie możliwości naruszenia bezpieczeństwa. Wobec powyższego musimy sprawdzić nowych opiekunów, zanim udostępnimy im konta na naszych serwerach i pozwolimy im wysyłać pakiety.
Zanim się tak naprawdę zarejestrujesz, powinieneś pokazać, że potrafisz solidnie pracować i będziesz dobrym współpracownikiem. Możesz to udowodnić, wysyłając łatki poprzez system śledzenia błędów lub posiadając przez jakiś czas pakiet sponsorowany przez istniejącego opiekuna. Oczekujemy także, że współpracownicy są zainteresowani całym projektem, a nie tylko opiekowaniem się własnymi pakietami. Jeśli możesz pomóc innym opiekunom przez dostarczenie dalszych informacji na temat błędu, lub nawet łatki, to zrób to!
Rejestracja wymaga, abyś był zaznajomiony z filozofią Debiana i dokumentacją
techniczą. Co więcej, potrzebujesz klucza GnuPG podpisanego przez istniejącego
opiekuna Debiana. Jeśli Twój klucz GnuPG nie jest jeszcze podpisany,
powinieneś spróbować spotkać się z opiekunem Debiana osobiście, aby otrzymać
podpis na kluczu. Istnieje strona
koordynacji podpisywania kluczy GnuPG, która powinna pomóc Ci
znaleźć opiekuna blisko Ciebie. (Jeśli nie możesz znaleźć opiekuna Debiana
blisko Ciebie, skorzystaj z alternatywnego sposobu sprawdzenia tożsamości.
Możesz przesłać dokument tożsamości z fotografią podpisany Twoim kluczem GnuPG.
Podpisywanie kluczy GnuPG jest jednak preferowanym sposobem. Zobacz stronę o
identyfikacji, aby dowiedzieć się więcej na temat tych dwóch opcji.)
Jeśli nie posiadasz jeszcze klucza OpenPGP, stwórz go. Każdy rozwijający potrzebuje klucza OpenPGP, aby podpisywać i weryfikować wysyłane pakiety. Powinieneś przeczytać instrukcje dotyczące oprogramowania, którego używasz, ponieważ posiadają one wiele bardzo ważnych informacji, krytycznych z punktu widzenia bezpieczeństwa. Dużo więcej błędów bezpieczeństwa następuje wskutek błędu ludzkiego niż błędu oprogramowania lub wysoko rozwiniętych technik szpiegowania. Zobacz rozdział Opieka nad swoimi kluczami, Rozdział 3.2, aby dowiedzieć się więcej na temat opiekowania się Twoim kluczem publicznym.
Debian używa GNU Privacy Guard (pakiet gnupg wersja 1
lub późniejsza) jako podstawowego standardu. Możesz wybrać także inną
implementację OpenPGP. Zauważ, że OpenPGP jest otwartym standardem opartym na
RFC 2440.
Polecanym algorytmem klucza publicznego, do używania podczas pracy nad rozwojem
Debiana, jest DSA (czasem nazywany ,,DSS'' lub ,,DH/ElGamal''). Jednakże mogą
zostać użyte także inne typy kluczy. Długość Twojego klucza musi wynosić co
najmniej 1024 bity. Nie ma powodu, aby używać krótszych kluczy, a byłoby to
dużo mniej bezpieczne. Twój klucz musi być podpisany przez co najmniej Twój
własny ID użytkownika. Zabezpiecza to przed podmianą ID użytkownika.
gpg robi to automatycznie.
Jeśli Twój klucz publiczny nie jest umieszczony na serwerach kluczy publicznych
takich jak np. pgp5.ai.mit.edu, zajrzyj do dokumentacji dostępnej
lokalnie w /usr/share/doc/pgp/keyserv.doc. Dokument ten zawiera
instrukcje, jak umieścić Twój klucz na publicznych serwerach kluczy. Grupa
Nowych Opiekunów (The New Maintainer Group) umieści Twój klucz publiczny na
serwerach, jeśli go tam jeszcze nie ma.
Niektóre kraje nakładają ograniczenia na używanie oprogramowania kryptograficznego przez ich obywateli. Jednak nie musi to przeszkadzać w opiekowaniu się pakietem Debiana, ponieważ używanie produktów kryptograficznych w celach potwierdzenia tożsamości, a nie szyfrowania danych, może być całkowicie legalne. Debian GNU/Linux nie wymaga używania kryptografii rozumianej jako kryptografia dowolnego rodzaju. Jeśli mieszkasz w kraju, w którym używanie kryptografii w celach potwierdzenia tożsamości także jest zabronione, skontaktuj się z nami, abyśmy mogli dokonać dla Ciebie specjalnych ustaleń.
Aby zgłosić się jako nowy opiekum, istniejący opiekun Debiana musi potwierdzić Twoje zgłoszenie (tzw. adwokat). Jak już będziesz współpracował z Debianem przez jakiś czas i będziesz chciał zgłosić się do rejestracji jako rozwijający, istniejący rozwijający, z którym współpracowałeś przez ostatnie miesiące, będzie musiał wyrazić swoją wiarę w to, że będziesz współpracował dla Debiana z powodzeniem.
Jeśli już znalazłeś adwokata, masz podpisany klucz GnuPG i współpracowałeś z
Debianem przez jakiś czas, jesteś gotowy do zgłoszenia. Po prostu zarejestruj
się na naszej stronie
zgłoszenia. Jak już się zapiszesz, Twój adwokat musi potwierdzić
Twoje zgłoszenie. Kiedy Twój adwokat zakończy ten krok, zostaniesz
przydzielony do Zarządzającego Zgłoszeniami (Application Manager), który
przeprowadzi Cię przez potrzebne kroki w procesie stawania się Nowym Opiekunem.
Zawsze możesz sprawdzić swój stan na stronie stanu zgłoszenia.
Aby dowiedzieć się więcej, zajrzyj na strony Kącika Nowych
Opiekunów w serwisie Debiana. Upewnij się, że jesteś zaznajomiony z
potrzebnymi krokami w procesie stawania się Nowym Opiekunem, zanim tak naprawdę
się zgłosisz. Jeśli będziesz dobrze przygotowany, zaoszczędzisz sobie później
wiele czasu.
Lista dyskusyjna debian-mentors@lists.debian.org
została stworzona dla początkujących opiekunów, którzy poszukują pomocy we
wczesnym stadium pakietowania lub w innych sprawach związanych z tworzeniem
dystrybucji. Każdego rozwijającego zachęca się do zapisania na tę listę (aby
dowiedzieć się więcej, zajrzyj do Listy dyskusyjne,
Rozdział 4.1).
Ci, którzy wolą pomoc osobistą (np. poprzez prywatną pocztę elektroniczną), powinni także wysyłać wiadomości na tą listę, aby doświadczony rozwijający zgłosił się do pomocy.
Dodatkowo, jeśli masz jakieś pakiety gotowe do włączenia do Debiana, ale
czekasz jeszcze na przejście Twojego zgłoszenia jako nowego opiekuna, możesz
znaleźć sponsora, który wyśle pakiet za Ciebie. Sponsorzy to ludzie, którzy są
oficjalnymi opiekunami Debiana i którzy są chętni do oceniania i wysyłania
Twoich pakietów za Ciebie. Poszukujący sponsora mogą zgłosić to na stronie
http://www.internatif.org/bortzmeyer/debian/sponsor/.
Jeśli chcesz zostać mentorem i/lub sponsorem, więcej informacji znajdziesz w Interakcja z przyszłymi deweloperami Debiana, Rozdział 7.5.
Istnieje baza danych LDAP https://db.debian.org/, zawierająca
informacje o deweloperach Debiana. Powinieneś wprowadzić tam informacje o
sobie i pamiętać o ich aktualizowaniu. W szczególności musisz być pewien, czy
adres, na który przesyłane są wiadomości poczty elektronicznej z debian.org
jest zawsze aktualny, podobnie jak i adres, na który subskrybujesz wiadomości -
jeżeli oczywiście takowej subskrypcji dokonałeś.
Aby uzyskać więcej informacji o bazie danych, zapoznaj się z Baza danych deweloperów, Rozdział 4.5.
Postępuj bardzo ostrożnie ze swoimi kluczami prywatnymi. Nie umieszczaj ich na
żadnych publicznych serwerach ani komputerach używanych przez wielu
użytkowników, takich jak serwery Debiana (patrz Maszyny Debiana, Rozdział 4.4). Wykonaj kopię
swoich kluczy i przechowuj ją poza komputerem. Zapoznaj się z dokumentacją
dostarczoną do Twojego oprogramowania oraz z PGP FAQ.
Jeżeli dodajesz sygnatury lub informacje identyfikujące użytkownika do Twojego
klucza publicznego, możesz aktualizować zestaw kluczy Debiana poprzez
przesłanie Twojego klucza na serwer kluczy keyring.debian.org.
Jeżeli natomiast chcesz dodać kompletnie nowy klucz lub usunąć stary, wyślij
list do keyring-maint@debian.org. Te
same metody postępowania z kluczami omówione zostały w Rejestrowanie się jako rozwijający Debiana., Rozdział
2.2.
Bardziej szczegółowe informacje na temat zastosowania kluczy w Debianie
znajdują się w dokumentacji pakietu debian-keyring.
Mimo, iż w Debianie nie panuje prawdziwa demokracja, to jednak używamy
demokratycznych metod do wyboru naszych liderów, a także podczas zatwierdzania
powszechnych rezolucji. Procedury te opisane zostały w Statucie Debiana.
Inaczej niż podczas corocznych wyborów liderów, głosowania nie należą do
czynności rutynowych i nie odbywają się one z błahych powodów. Każda
propozycja jest najpierw poddawana dyskusji na liście dyskusyjnej debian-vote@lists.debian.org,
a zanim zostanie uruchomiona procedura głosowania przez sekretarza projektu,
propozycja musi uzyskać szersze poparcie.
Nie musisz śledzić dyskusji toczących się przed głosowaniem, gdyż sekretarz
będzie wzywał do głosowania na debian-devel-announce@lists.debian.org
(oczekuje się, że wszyscy deweloperzy są zapisani na tę listę). Demokracja nie
funkcjonuje dobrze, jeżeli ludzie nie biorą udziału w głosowaniu, dlatego też
zachęcamy wszystkich deweloperów do głosowania. Głosowanie jest przeprowadzane
za pomocą podpisanych/zaszyfrowanych (GPG) wiadomości poczty elektronicznej.
Lista wszystkich propozycji (wcześniejszych i obecnych) dostępna jest na
stronie Informacji dotyczących
głosowania w Debianie, wraz z informacjami, jak tworzyć propozycje i
nad nimi głosować.
Normalną sprawą dla deweloperów są okresy absencji, podczas których wypoczywają lub po prostu pochłonięci są inną pracą. Ważne jest, aby inni deweloperzy wiedzieli o Twojej nieobecności, tak aby w razie zaistnienia jakichś problemów związanych z Twoimi pakietami lub innymi obowiązkami w projekcie, mogli podjąć wszelkie niezbędne działania.
Zwykle oznacza to, że inni deweloperzy mają możliwość NMU (patrz Przesyłanie pakietów przez nieoficjalnego opiekuna (Non-Maintainer Uploads (NMU)), Rozdział 5.11) Twojego pakietu, jeżeli pojawi się poważny problem (błędy krytyczne dla wydania, aktualizacje bezpieczeństwa, etc.) podczas Twojej nieobecności. Czasami nie jest to aż tak poważne, ale mimo to nadal właściwym pozostaje poinformować innych, że jesteś nieosiągalny.
W celu poinformowania innych deweloperów powinieneś zrobić dwie rzeczy.
Najpierw wyślij list do debian-private@lists.debian.org
ze zwrotem "[VAC] " w temacie Twojej wiadomości[1] oraz podanym okresem, w jakim będziesz na urlopie. Możesz
także podać kilka specjalnych instrukcji, co robić w przypadku, gdy pojawi się
problem.
Następną rzeczą jest oznaczenie siebie jako "on vacation" w bazie danych LDAP deweloperów Debiana (informacja ta jest dostępna jedynie dla deweloperów Debiana). Nie zapomnij usunąć znacznika "on vacation" po powrocie!
Sporą część Twojej pracy jako opiekuna Debiana stanowić będzie utrzymywanie kontaktu z zewnętrznymi deweloperami. Użytkownicy Debiana czasami zgłaszają raporty o błędach, które dla naszego systemu śledzenia błędów nie są właściwie błędami w Debianie. Powinieneś przesłać takie raporty do zewnętrznych deweloperów, aby błędy te mogły zostać naprawione w przyszłym wydaniu.
Mimo, że naprawianie błędów nie będących specyficznymi błędami Debiana nie jest twoim zadaniem, to jednak możesz swobodnie się tego podjąć. Wykonując takie poprawki upewnij się, że przesłałeś je dalej - także do opiekuna pakietu. Użytkownicy oraz deweloperzy Debiana będą niekiedy przedstawiać łaty naprawiające zewnętrzne błędy -- powinieneś ocenić je i przesłać dalej.
Jeśli chcesz modyfikować zewnętrzne źródła tak, aby zbudować pakiet zgodny z polityką Debiana, powinieneś zaproponować zewnętrznemu deweloperowi poprawkę, którą można zaimplementować tak, abyś nie musiał modyfikować źródeł w następnej wersji programu. Jakichkolwiek zmian potrzebujesz, nigdy nie próbuj rozdzielać ich od zewnętrznego źródła.
Ogólnie rzecz biorąc, raportowanymi błędami dotyczącymi Twoich pakietów powinieneś zajmować się zgodnie z tym, co opisano w Obsługa błędów, Rozdział 5.8. Niemniej jednak istnieje specjalna kategoria błędów, o którą szczególnie musisz zadbać - tak zwane błędy krytyczne dla wydania (release-critical bugs - RC bugs). Wszystkie raportowane błędy z ważnością critical, grave lub serious są uważane za mające wpływ na to, czy pakiet może być wydany w następnej stabilnej dystrybucji Debiana. Takie błędy mogą opóźnić wydanie Debiana i/lub mogą uzasadniać usunięcie pakietu w okresie zamrożenia dystrybucji. Właśnie dlatego takie błędy muszą być poprawiane tak szybko, jak to możliwe.
Deweloperzy, którzy należą do grupy Quality Assurance, śledzą wszelkie
takie błędy i starają się pomóc, jak to tylko możliwe. Jeżeli z jakiegoś
powodu nie jesteś w stanie naprawić błędu RC w Twoim pakiecie w ciągu dwóch
tygodni, powinieneś poprosić o pomoc wysyłając list do grupy odpowiedzialnej za
zapewnienie jakości (QA) debian-qa@lists.debian.org,
lub też ewentualnie zgłosić raport o błędzie, wyjaśniając trudności związane z
błędem oraz plan naprawy. W przeciwnym razie osoby z grupy QA mogą dokonać
tzw. Non-Maintainer Upload (patrz Przesyłanie pakietów przez
nieoficjalnego opiekuna (Non-Maintainer Uploads (NMU)), Rozdział 5.11) po
próbie kontaktu z Tobą (okres czasu, zanim dokonają oni NMU, może być krótszy
niż zazwyczaj, jeżeli nie zauważą oni świeżych śladów Twojej aktywności na
BTS).
Jeżeli zdecydujesz się opuścić projekt Debiana, upewnij się, że wykonałeś następujące kroki:
debian-private@lists.debian.org.
keyring-maint@debian.org.
W tym rozdziale znajdziesz bardzo zwięzły plan list dyskusyjnych Debiana, mechanizmów Debiana dostępnych dla Ciebie jako dewelopera, a także wszystkich pozostałych zasobów, które mogą Ci pomóc w Twojej pracy opiekuna.
Większość rozmów, jakie odbywają się między deweloperami Debiana (oraz
użytkownikami), prowadzona jest poprzez szerokie spektrum list dyskusyjnych
dostępnych na lists.debian.org. Aby
dowiedzieć się więcej o zapisywaniu i wypisywaniu z nich, jak na nie wysyłać, a
jak tego nie robić, gdzie znaleźć stare wiadomości i jak je wyszukiwać, jak
skontaktować się z opiekunami listy oraz zobaczyć różne inne informacje z nimi
związane, poczytaj http://www.debian.org/MailingLists/.
Ten rozdział opisuje tylko te aspekty list dyskusyjnych, które są szczególnie
ważne dla deweloperów.
Odpowiadając na wiadomości z listy dyskusyjnej, nie wysyłaj proszę jej kopii (carbon copy - CC) do wysyłającego, o ile wyraźnie o tę kopię nie poprosił. Każdy wysyłający na listę powinien ją czytać, aby zobaczyć odpowiedzi.
Cross-posty (wysyłanie tej samej wiadomości na wiele list) nie są mile widziane. Jak wszędzie w Internecie, odpowiadaj pod cytowanym fragmentem artykułu. Generalnie stosuj się proszę do zwyczajowej netykiety.
Więcej informacji dostępnych jest w zasadach odpowiedniego
zachowania
Głównymi listami dyskusyjnymi Debiana, które powinny być używane przez deweloperów, są:
debian-devel-announce@lists.debian.org,
używana do informowania deweloperów o ważnych rzeczach. Wszyscy deweloperzy są
zobowiązani do subskrybowania tej listy.
debian-devel@lists.debian.org,
używana do dyskusji nad różnymi sprawami technicznymi.
debian-policy@lists.debian.org,
gdzie dyskutuje się nad Polityką Debiana i gdzie odbywają się głosowania.
debian-project@lists.debian.org,
używana do dyskusji nad różnymi sprawami nietechnicznymi związanymi z
projektem.
Istnieje wiele innych list poświęconych rozmaitym, specjalnym tematom - zobacz
http://lists.debian.org/.
debian-private@lists.debian.org
jest specjalną listą dyskusyjną przeznaczoną do prywatnych dyskusji między
deweloperami Debiana. W zamierzeniu przeznaczona jest dla listów, które ze
względu na przyczynę nie powinny być publicznie dostępne. Jako taka jest
,,cichą'' listą, a użytkownicy są namawiani na korzystanie z debian-private@lists.debian.org
tylko w naprawdę niezbędnych przypadkach. Ponadto nie przekazuje
listów z tej listy na inne. Z oczywistych względów archiwum tej listy nie jest
dostępne na stronie internetowej, ale możesz je przejrzeć używając swojego
konta shellowego na lists.debian.org i zaglądając do katalogu
~debian/archive/debian-private.
debian-email@lists.debian.org
jest specjalną listą dyskusyjną używaną jako zbiorcza skrzynka do
korespondencji związanej z Debianem - takiej jak kontakt z zewnętrznymi
autorami w sprawie licencji, błędów itp. lub dyskusji nad projektem, przy
której mogłoby być użyteczne posiadanie gdzieś jej archiwum.
Zanim zgłosisz chęć założenia listy związanej z rozwijaniem pakietu (lub małej grupy powiązanych pakietów), przemyśl, czy nie lepiej użyć aliasów (poprzez plik .forward-nazwaaliasu na master.debian.org, który przekłada się na całkiem rozsądny adres postaci twojlogin-nazwaaliasu@debian.org) czy też własnoręcznie zarządzanej listy dyskusyjnej na Alioth.
Jeśli zdecydujesz, że naprawdę potrzebujesz listy dyskusyjnej na
lists.debian.org, wypełnij formularz zgodnie z opisem HOWTO.
Rozwojowi Debiana poświęconych jest kilka kanałów IRC. Hostowane są one
głównie w sieci freenode
(wcześniej znanej jako Open Projects Network). Wpis w DNS
irc.debian.org jest aliasem do irc.freenode.net.
Głównym kanałem Debiana jest #debian. Jest to duży kanał ogólnego użytku, na którym użytkownicy mogą znaleźć ogłaszane przez boty w temacie (topic) ostatnie nowości. #debian jest przeznaczony dla ludzi mówiących po angielsku; istnieją również kanały #debian.de, #debian-fr, #debian-br oraz inne z podobną formą nazewnictwa - dla ludzi mówiących w innych językach.
Głównym kanałem deweloperów Debiana jest #debian-devel. Jest to bardzo aktywny kanał, jako że zawsze zalogowanych jest na nim ponad 150 osób. Jest przenaczony dla ludzi pracujących nad Debianem, a nie kanałem pomocy technicznej (do tego rodzaju spraw jest #debian). Mimo to jest on otwarty dla każdego, kto chce po cichu czegoś się nauczyć. Jego temat zazwyczaj zawiera sporo interesujących informacji przydatnych deweloperom.
Ponieważ #debian-devel jest kanałem otwartym, nie powinieneś na nim
rozmawiać o tematach podejmowanych na debian-private@lists.debian.org.
Do tego celu przeznaczony jest kanał pod nazwą #debian-private, który
jest zabezpieczony kluczem. Klucz dostępny jest w archiwum debian-private w
katalogu master.debian.org:~debian/archive/debian-private/ - po
prostu wykonaj zgrep na wszystkich plikach w poszukiwaniu słowa
#debian-private.
Istnieją inne dodatkowe kanały dedykowane konkretnym tematom. #debian-bugs jest używany do koordynacji błędów. #debian-boot to kanał przeznaczony do koordynacji pracy nad dyskietkami rozruchowymi (np. instalator). #debian-doc jest używany okazjonalnie do rozmów na temat dokumentacji, podobnej do tej, którą właśnie czytasz. Inne kanały poświęcone są innym architekturom lub zestawom pakietów: #debian-bsd, #debian-kde, #debian-jr, #debian-edu, #debian-sf (pakiet SourceForge), #debian-oo (pakiet OpenOffice)...
Istnieją również inne niż anglojęzyczne kanały dla deweloperów, na przykład #debian-devel-fr dla francuskojęzycznych ludzi zainteresowanych rozwijaniem Debiana.
Istnieją także kanały dedykowane Debianowi w innych sieciach IRC, szczególnie w
sieci otwartej społeczności (Open and free
technology community (OFTC))
Dokument ten zawiera wiele bardzo użytecznych informacji dla deweloperów
Debiana, ale nnie może zawierać wszystkiego. Większość innych interesujących
dokumentów ma odsyłacze w Kąciku
deweloperów. Znajdź więc trochę czasu na przejrzenie wszystkich
tych odsyłaczy, a na pewno dowiesz się o wiele więcej.
Debian posiada kilka komputerów pracujących jako serwery, których większość pełni krytyczne funkcje w projekcie. Większość z nich używana jest do czynności przenoszenia pakietów na inne architektury i wszystkie mają stałe połączenie z Internetem.
Większość komputerów dostępna jest do użytku dla poszczególnych deweloperów,
dopóki stosują się oni do Polityki Używania Maszyny
Debiana.
Ogólnie rzecz biorąc, możesz używać tych maszyn do celów związanych z Debianem. Proszę, bądź uprzejmy dla administratorów systemu i nie używaj przestrzeni dyskowej, pasma sieciowego czy CPU bez uprzedniej zgody administratora systemu. Zazwyczaj maszyny te są utrzymywane przez ochotników.
Proszę, zabezpiecz należycie swoje debianowe hasła i klucze SSH zainstalowane na maszynach Debiana. Unikaj logowania czy metod przesyłania pakietów używających przy wysyłaniu haseł przez Internet czystego tekstu, takich jak telnet, FTP, POP itp.
Nie umieszczaj, proszę, na serwerach Debiana żadnych dokumentów nie powiązanych z Debianem, chyba że dostałeś na to wyraźną zgodę.
Aktualna lista maszyn Debiana dostępna jest na http://db.debian.org/machines.cgi.
Strona ta zawiera nazwy maszyn, informacje kontaktowe, informacje o tym, kto
może się na nie logować, klucze SSH itp.
Jeśli masz problem z obsługą serwera Debiana i myślisz, że powinieneś o tym
powiadomić operatorów systemu, zespół administratorów osiągalny jest pod
adresem debian-admin@lists.debian.org.
Jeśli masz problem z określoną usługą nie związaną z administrowaniem systemem (taki jak problem z usunięciem pakietu z archiwum, sugestie co do stron internetowych itp.) zgłoś błąd pseudo-pakietu. Informacje na temat zgłaszania błędów - zobacz Zgłaszanie błędów, Rozdział 7.1.
bugs.debian.org jest kanoniczną lokalizacją Systemu Śledzenia
Błędów (BTS). Jeśli planujesz robić jakieś analizy statystyczne lub obsługę
błędów Debiana, to jest właśnie odpowiednie na to miejsce. Zanim jednak
cokolwiek zaimplementujesz, opisz, proszę, swoje plany na debian-devel@lists.debian.org,
dzięki czemu można będzie wykluczyć niepotrzebne powtórki i nie tracić
niepotrzebnie czasu.
Wszyscy deweloperzy Debiana posiadają konta na bugs.debian.org.
Serwer ftp-master.debian.org utrzymuje kanoniczną kopię archiwum Debiana (oprócz pakietów non-US). Ogólnie rzecz biorąc, na ten serwer trafiają przesyłane pakiety. Zobacz Umieszczanie pakietów w archiwum, Rozdział 5.6.
Ogólne problemy z archiwum FTP Debiana muszą być zgłaszane jako błędy
pseudo-pakietu ftp.debian.org lub na adres poczty elektronicznej
ftpmaster@debian.org.
Zapoznaj się również z procedurami opisanymi w podrozdziale Przenoszenie, zmiana nazwy, adopcja i osierocanie
pakietów, Rozdział 5.9.
Serwer non-US, non-us.debian.org, utrzymuje kanoniczną kopię części archiwum Debiana non-US. Jeśli musisz przesłać pakiet do jednej z sekcji non-US, prześlij go na ten serwer; zobacz Przesyłanie do non-US, Rozdział 5.6.2.
Problemy z archiwum pakietów non-US powinny być zasadniczo zgłaszane jako błąd
pseudo-pakietu nonus.debian.org (zauważ brak kreski między ``non''
i ``us'' w nazwie pseudo-pakietu — jest to związane ze wsteczną
zgodnością). Pamiętaj o sprawdzeniu, czy ktoś inny już nie zgłosił tego
problemu do Systemu
Śledzenia Błędów.
Głównym serwerem www jest www-master.debian.org. Umieszczone są na nim oficjalne strony internetowe, ,,twarz'' Debiana dla większości nowych użytkowników.
Jeśli znajdziesz problem z serwerem www Debiana, powinieneś zgłosić błąd
pseudo-pakietu www.debian.org. Pamiętaj o sprawdzeniu, czy ktoś
inny już nie zgłosił tego problemu do Systemu Śledzenia
Błędów.
people.debian.org jest serwerem przeznaczonym na własne strony internetowe deweloperów, poświęcone wszystkiemu, co ma związek z Debianem.
Jeśli posiadasz jakieś specyficzne informacje o Debianie, które chciałbyś
umieścić w sieci, możesz to zrobić umieszczając materiał w katalogu
public_html znajdującym się w Twoim katalogu domowym na
people.debian.org. Będzie on dostępny pod adresem
http://people.debian.org/~twoja-nazwa-uzytkownika/.
Powinieś używać tylko tej określonej lokalizacji, ponieważ wszystko będzie archiwizowane, podczas gdy na innych hostach tak się nie dzieje.
Jedyną przyczyną, która jest zazwyczaj powodem używania innego hosta, jest sytuacja, gdy musisz opublikować materiały objęte restrykcjami eksportowymi USA. W tym przypadku możesz użyć jednego z serwerów położonych poza granicami Stanów Zjednoczonych, na przykład wymienionego wcześniej non-us.debian.org.
Jeśli masz jakiekolwiek pytania, wyślij list do debian-devel@lists.debian.org.
Nasz serwer CVS jest zlokalizowany na cvs.debian.org.
Jeśli chcesz używać publicznie dostępnego serwera CVS, przykładowo do koordynacji pracy nad pakietem między różnymi deweloperami, możesz poprosić o obszar w CVS na serwerze.
Ogólnie rzecz biorąc, cvs.debian.org oferuje kombinację lokalnego
dostępu CVS, anonimowego dostępu klient-serwer w trybie tylko do odczytu i
pełnego dostępu klient-serwer poprzez ssh. Poza tym, obszar CVS
może być dostępny w trybie tylko do odczytu poprzez stronę www na http://cvs.debian.org/.
Prośbę o obszar w CVS wyślij na debian-admin@debian.org.
Załącz proponowaną nazwę obszaru CVS, nazwę konta, które powinno być
właścicielem głównego obszaru CVS i informację o tym, dlaczego go potrzebujesz.
Baza danych deweloperów, dostępna na https://db.debian.org/, jest
katalogiem LDAP do zarządzania atrybutami deweloperów Debiana. Możesz używać
tego zasobu do przeszukiwania listy deweloperów Debiana. Część z tych
informacji jest również dostępna poprzez usługę finger na serwerach Debiana;
spróbuj polecenia finger twojlogin@db.debian.org i zobacz, o czym
Cię poinformuje.
Deweloperzy mogą logować się
do bazy danych, aby zmieniać różne informacje na swój temat, takie
jak:
mapie świata deweloperów
Debiana, numery telefonów i faksów, pseudo na IRC czy strona
internetowa
Naturalnie większość informacji nie jest dostępna publicznie. Więcej
informacji jest dostępnych w dokumentacji online, którą można znaleźć na
http://db.debian.org/doc-general.html.
Można jej również użyć do otrzymania kluczy SSH wykorzystywanych do autoryzacji
na oficjalnych maszynach Debiana, a nawet dodać nowy wpis DNS *.debian.net.
Właściwości te są udokumentowane na http://db.debian.org/doc-mail.html.
Dystrybucja Debian GNU/Linux składa się z wielu pakietów (.deb,
dotychczas około 9000) i kilku dodatkowych plików (takich jak dokumentacja czy
obrazy dysków instalacyjnych).
Poniżej znajduje się przykładowe drzewo katalogów kompletnego archiwum Debiana:
dists/stable/main/
dists/stable/main/binary-i386/
dists/stable/main/binary-m68k/
dists/stable/main/binary-alpha/
...
dists/stable/main/source/
...
dists/stable/main/disks-i386/
dists/stable/main/disks-m68k/
dists/stable/main/disks-alpha/
...
dists/stable/contrib/
dists/stable/contrib/binary-i386/
dists/stable/contrib/binary-m68k/
dists/stable/contrib/binary-alpha/
...
dists/stable/contrib/source/
dists/stable/non-free/
dists/stable/non-free/binary-i386/
dists/stable/non-free/binary-m68k/
dists/stable/non-free/binary-alpha/
...
dists/stable/non-free/source/
dists/testing/
dists/testing/main/
...
dists/testing/contrib/
...
dists/testing/non-free/
...
dists/unstable
dists/unstable/main/
...
dists/unstable/contrib/
...
dists/unstable/non-free/
...
pool/
pool/main/a/
pool/main/a/apt/
...
pool/main/b/
pool/main/b/bash/
...
pool/main/liba/
pool/main/liba/libalias-perl/
...
pool/main/m/
pool/main/m/mailx/
...
pool/non-free/n/
pool/non-free/n/netscape/
...
Jak widzisz, najwyższy poziom zawiera dwa katalogi: dists/ i
pool/. Drugi z nich, “pool”, jest katalogiem, w
którym rzeczywiście znajdują się pakiety i który jest obsługiwany przez bazę
danych archiwum i towarzyszące jej programy. Pierwszy zawiera dystrybucję
stable (stabilną), testing (testową) oraz unstable
(niestabilną). Pliki Packages i Sources w
podkatalogach dystrybucji mogą odsyłać do plików w katalogu pool/.
Drzewo katalogów jest zaaranżowane w ten sam sposób dla każdej dystrybucji.
Poniższy opis stable jest dokładnie taki sam, jak w przypadku
unstable i testing
dists/stable zawiera trzy katalogi nazwane main,
contrib oraz non-free.
W każdym z nich istnieje katalog dla pakietów źródłowych (source)
oraz katalog dla każdej obsługiwanej architektury (binary-i386,
binary-m68k itp.).
Katalog main zawiera dodatkowe katalogi, w których umieszczone są
obrazy dysku oraz pewne istotne części dokumentacji niezbędne przy instalacji
dystrybucji Debiana na poszczególnych architekturach (disks-i386,
disks-m68k itp.).
Sekcja main archiwum Debiana zawiera to, co składa się na oficjalną dystrybucję Debian GNU/Linux. Sekcja main jest oficjalną, ponieważ w pełni uwzględnia nasze wytyczne. Pozostałe dwie sekcje tego nie uwzględniają; jako takie nie są oficjalną częścią Debian GNU/Linux.
Każdy pakiet w sekcji main musi być w pełni zgodny z Wytycznymi Debiana
dotyczącymi Wolnego Oprogramowania (DFSG) oraz z wszystkimi innymi
wymaganiami polityki Debiana opisanymi w Podręczniku Polityki
Debiana. DFSG jest naszą definicją “wolnego
oprogramowania.” Więcej szczegółów w Podręczniku Polityki Debiana.
Pakiety z sekcji contrib muszą stosować się do DFSG, ale mogą nie spełniać innych wymagań. Przykładowo mogą być zależne od pakietów non-free.
Pakiety nie stosujące się do DFSG są wstawiane do sekcji non-free. Nie są one pomyślane jako część dystrybucji Debiana, choć wspomagamy ich używanie oraz dostarczamy infrastrukturę (taką jak nasz system śledzenia błędów czy listy dyskusyjne).
Podręcznik Polityki
Debiana zawiera dokładniejsze definicje tych trzech sekcji.
Powyższa dyskusja jest jedynie wstępem.
Oddzielenie od siebie tych trzech sekcji w głównym archiwum jest ważne dla wszystkich ludzi chcących dystrybuować Debiana - bądź to przez serwery FTP, bądź na CDROMach: dystrybuując tylko sekcje main oraz contrib, mogą oni uniknąć ryzyka naruszenia przepisów. Na przykład niektóre pakiety w non-free nie są przeznaczone do zastosowań komercyjnych.
Z drugiej strony, ludzie rozprowadzający CDROMy mogą w łatwy sposób sprawdzić licencje poszczególnych pakietów z non-free i załączyć ich tylko tyle, na ile pozwalają te licencje. (Ponieważ zależne jest to od danego dostawcy, prace te nie mogą być wykonywane przez deweloperów Debiana).
Zauważ też, że termin ,,sekcja'' używany jest również w odniesieniu do kategorii, które ułatwiają organizację i przeglądanie dostępnych pakietów, np. admin, net, utils itp. Kiedyś sekcje te (a raczej podsekcje) istniały w formie podkatalogów w obrębie archiwum Debiana. Obecnie istnieją one tylko w nagłówku pola ,,Section'' pakietów.
Początkowo jądro Linuksa dostępne było tylko dla platform intelowskich i386 (lub nowszych), więc tak samo rzecz miała się w Debianie. Ale z czasem, gdy Linux stawał się coraz bardziej popularny, jądro zostało również zaadaptowane dla innych architektur.
Jądro Linuksa w wersji 2.0 obsługuje architektury Intel x86, DEC Alpha, SPARC, Motorola 680x0 (jak Atari, Amiga i Macintosh), MIPS i PowerPC. Jądro Linuksa wersji 2.2 obsługuje jeszcze więcej architektur, włączając w to ARM i UltraSPARC. Od kiedy Linux obsługuje te platformy, Debian zdecydował, że on też powinien tak zrobić. Efektem tego Debian przeniósł pakiety na inne architektury; w praktyce adaptujemy też jądro nie-linuksowe. Obok i386 (nasze nazewnictwo Intela x86) istnieją też m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, mipsel oraz sh.
Debian GNU/Linux 1.3 jest dostępny tylko na i386. Debiana 2.0 dostarczano na architektury i386 i m68k. Debiana 2.1 rozprowadzano na architektury i386, m68k, alpha i sparc. Debian 2.2 obługiwał dodatkowo powerpc i arm. Do Debiana 3.0 dodano obsługę pięciu nowych architektur: ia64, hppa, s390, mips i mipsel.
Informacje dla deweloperów i użytkowników dotyczące poszczególnych portów
dostępne są na stronach Portów
Debiana.
Istnieją dwa typy pakietów Debiana, tzw. pakiety źródłowe (source) oraz binarne (binary).
Pakiety źródłowe składają się z dwóch albo trzech plików: pliku
.dsc oraz .tar.gz lub obu .orig.tar.gz i
.diff.gz
Jeśli pakiet jest tworzony specjalnie dla Debiana i nie jest dystrybuowany poza
Debianem, zawiera tylko jeden z nich: plik .tar.gz, który zawiera
źródła programu. Jeżeli zaś pakiet jest również dostarczany gdzie indziej,
plik .orig.tar.gz przechowuje tak zwany zewnętrzny kod
źródłowy, co oznacza kod dystrybuowany przez zewnętrznego
opiekuna (często jest nim autor programu). W tym przypadku plik
.diff.gz zawiera zmiany wykonane przez opiekuna Debiana.
Plik .dsc zawiera listę wszystkich plików w pakiecie źródłowym
razem z sumami kontrolnymi (md5sums) oraz pewne dodatkowe
informacje o pakiecie (opiekun, wersja itp.).
System katalogowy opisany w poprzednim rozdziale jest sam zawarty w obrębie
katalogów dystrybucji. Każda dystrybucja jest w rzeczywistości
zawarta w katalogu pool na najwyższym poziomie archiwum Debiana.
Podsumowując, archiwum Debiana posiada główny katalog na serwerze FTP.
Przykładowo na serwerze lustrzanym ftp.us.debian.org, samo
archiwum Debiana umieszczone jest w /debian, które jest powszechną
lokalizacją (inną jest /pub/debian).
Dystrybucja mieści w sobie źródła Debiana i pakiety binarne oraz indywidualne
indeksowane pliki Sources i Packages, zawierające
informacje nagłówkowe wszystkich tych pakietów. Pierwszy z nich przechowywany
jest w katalogu pool/, podczas gdy drugi znajduje się w katalogu
archiwum dists/ (dla wstecznej kompatybilności).
Zawsze istnieją dystrybucje zwane stabilną (stable) (umieszczona w
dists/stable), testową (testing) (umieszczona w
dists/testing) i niestabilną (unstable) (umieszczona w
dists/unstable). Odzwierciedlają one proces rozwijania projektu
Debiana.
Rozwój aktywny wykonywany jest w dystrybucji niestabilnej (dlatego czasami dystrybucja ta nazywana jest dystrybucją rozwojową). Każdy deweloper Debiana może w każdym momencie aktualizować swoje pakiety w tej dystrybucji. Tak więc zawartość tej dystrybucji zmienia się z dnia na dzień. Ponieważ nie przykłada się większej uwagi do tego, czy wszystko działa prawidłowo w tej dystrybucji, czasami jest ona dosłownie niestabilna.
Dystrybucja Więcej informacji o dystrybucji testowej, Rozdział 4.6.4.2 jest generowana automatycznie poprzez przeniesienie pakietów z dystrybucji niestabilnej, jeśli spełniają one określone kryteria. Te kryteria powinny zapewnić dobrą jakość pakietów podczas testowania. Aktualizacja dystrybucji testowej jest uruchamiana każdego dnia po zainstalowaniu nowych pakietów.
Po okresie rozwijania, gdy opiekun wydania (Release Manager) uważa ją za odpowiednią, dystrybucja testowa jest zamrażana, co oznacza że zacieśnia się politykę określającą kontrolę przenoszenia pakietów z niestabilnej do testowej. Pakiety najeżone błędami są usuwane. Nie można wykonywać w tym czasie żadnych zmian oprócz usuwania błędów. Po upływie pewnego czasu zależnego od postępu prac, dystrybucja testowa jest ``głęboko zamrażana''. W tym okresie nie są wykonywane żadne zmiany z wyjątkiem niezbędnych do instalacji systemu. Nazywa się to “cyklem testowym” i może trwać do 2 tygodni. Może być kilka cyklów testowych, zanim dystrybucja będzie przygotowana do wydania. Decyduje o tym opiekun wydania. Na koniec ostatniego cyklu testowego, zmienia się nazwę dystrybucji testowej na stabilną, nadpisując starą dystrybucję stabilną, która jest w tym momencie usuwana (mimo to można ją znaleźć na archive.debian.org).
Ten cykl rozwojowy oparty jest na założeniu, iż dystrybucja
niestabilna staje się stabilną po przejściu okresu
testowego. Nawet gdy dystrybucję uważa się za stabilną, nieuniknione
jest przedostanie się do niej kilku błędów — to jest właśnie przyczyną
aktualizacji dystrybucji stabilnej co jakiś czas. Niemniej jednak te
aktualizacje testowane są bardzo uważnie i muszą być indywidualnie zgłaszane do
archiwum w celu zredukowania ryzyka wprowadzenia nowych błędów. Proponowane
dodatki dystrybucji stabilnej można znaleźć w katalogu
proposed-updates. Pakiety z tego katalogu, które przejdą
selekcję, są co jakiś czas grupowo przenoszone do dystrybucji stabilnej, a
numer wersji dystrybucji jest zwiekszany (np. ‘3.0’ staje się
‘3.0r1’, ‘2.2r4’ staje się ‘2.2r5’, itd.).
Zauważ że rozwój pakietów z dystrybucji niestabilnej jest kontynuowany podczas okresu zamrożenia, ponieważ dystrybucja niestabilna istnieje równolegle z testową.
Skrypty aktualizujące dystrybucję testową są uruchamiane każdego dnia
po instalacji zaktualizowanych pakietów. Generują one pliki
Packages dla dystrybucji testowej, ale robią to w
inteligentny sposób, próbując uniknąć wszystkich nezgodności oraz używać tylko
pakietów wolnych od błędów.
Włączenie pakietu z dystrybucji niestabilnej jest uwarunkowane następującymi rzeczami:
madison,
Rozdział 4.9.2 może być interesujący przy sprawdzaniu tej informacji;
Aby dowiedzieć się, czy pakiet jest w trakcie testowania, obejrzyj wyniki
skryptu testującego na stronie dystrybucji
testowej lub użyj programu grep-excuses z pakietu
devscripts. Narzędzie to może być łatwo używane w
crontab(5) informując o aktualnym postępie przenoszenia pakietów
do dystrybucji testowej.
Plik update_excuses nie zawsze podaje dokładną przyczynę
odrzucenia pakietu, trzeba więc ją znaleźć samodzielnie szukając w pakiecie, co
spowodowało błąd. Strony
dystrybucji testowej podają trochę informacji na temat zwyczajowych
problemów, które mogą spowodować tego rodzaju kłopoty.
Czasami pakiet w ogóle nie trafia do dystrybucji testowej, ponieważ ustawienia zależności są zbyt skomplikowane i nie mogą być one przesortowane przez skrypty. W takim przypadku należy skontaktować się z opiekunem wydania, który wymusi włączenie pakietu do dystrybucji testowej.
Generalnie więcej informacji dostępnych jest na stronie dystrybucji
testowej. Zawiera ona również odpowiedzi na niektóre z najczęściej
zadawanych pytań.
Dystrybucja eksperymentalna (experimental) jest dystrybucją specjalną. Nie jest to pełna dystrybucja, tak jak jest to w przypadku `stabilnej' czy `niestabilnej'. Można ją określić jako tymczasowy obszar z wysoce eksperymentalnym oprogramowaniem, w którym istnieje spora szansa, że dane oprogramowanie może spowodować załamanie systemu, lub aplikacje są nawet bardziej niestabilne od tych w dystrybucji niestabilnej (ale mimo wszystko są tworzone z nich pakiety). Użytkownicy pobierający i instalujący pakiety z dystrybucji eksperymentalnej prawdopodobnie zostaną dokładnie ostrzeżeni. W skrócie, w dystrybucji eksperymentalnej zdarzyć może się wszystko.
Poniżej przedstawiono linie z pliku sources.list(5) przeznaczone
dla dystrybucji eksperymentalnej:
deb http://ftp.xy.debian.org/debian/ ../project/experimental main
deb-src http://ftp.xy.debian.org/debian/ ../project/experimental main
Jeśli istnieje szansa spowodowania przez oprogramowanie poważnej awarii systemu, lepiej będzie, gdy zostanie ono umieszczone w dystrybucji eksperymentalnej. Przykładowo eksperymentalny skompresowany system plików prawdopodobnie powinien trafić do dystrybucji eksperymentalnej.
Zawsze kiedy pojawi się nowa zewnętrzna wersja pakietu, która wprowadza nowe możliwości, ale usuwa kilka starszych, nie powinna być w ogólne przesyłana, albo przesyłana do dystrybucji eksperymentalnej. Nowe beta wersje pewnych aplikacji, które używają kompletnie zmienionej konfiguracji, mogą być wstawiane do dystrybucji eksperymentalnej wedle uznania opiekuna. Jeśli pracujesz na niekompatybilnych lub skomplikowanych programach, również możesz użyć dystrybucji eksperymentalnej jako obszaru pomostowego, tak by testerzy mogli mieć do nich wcześniejszy dostęp.
Pewne eksperymentalne programy mogą w dalszym ciągu być przesyłane do dystrybucji niestabilnej z kilkoma ostrzeżeniami w opisie, ale nie jest to zalecane, ponieważ pakiety z niestabilnej są przeznaczone dla dystrybucji testowej, która de facto staje się później stabilną. Nie powinieneś obawiać się używania dystrybucji eksperymentalnej, ponieważ nie oddziałuje ona na ftpmaster, a pakiety eksperymentalne są automatycznie usuwane, kiedy przesyłasz pakiet do niestabilnej z wyższym numerem wersji.
Nowe oprogramowanie, które nie spowoduje ewentualnych szkód w systemie, może być umieszczane bezpośrednio w dystrybucji niestabilnej.
Alternatywą dla dystrybucji eksperymentalnej jest wykorzystanie swojej strony internetowej na people.debian.org.
Każde wydanie dystrybucji Debiana posiada swoją nazwę kodową: Debian 1.1 nazywany jest `buzz', Debian 1.2 - `rex', Debian 1.3 - `bo', Debian 2.0 - `hamm', Debian 2.1 - `slink', Debian 2.2 - `potato', a Debian 3.0 - `woody'. Istnieje również ``pseudo dystrybucja'' pod nazwą `sid', która jest aktualną dystrybucją `niestabilną'; Ponieważ pakiety są przenoszone z `niestabilnej' do `testowej' w trakcie przygotowania osiągania stabilności, `sid' jako taki nigdy nie zostanie wydany. Dystrybucja `sid' zawiera również pakiety na architektury, które nie są jeszcze oficjalnie obsługiwane przez Debiana, lub nie są jeszcze wydawane. Architektury te są planowane do zintegrowania z główną dystrybucją w pewnej nieodległej przyszłości.
Ponieważ Debian rozwijany jest w otwartym modelu (tj. każdy może uczestniczyć w jego rozwijaniu), nawet takie dystrybucje jak `niestabilna' czy `testowa' są rozprowadzane w Internecie poprzez serwery FTP i HTTP Debiana. Tak więc jeśli mielibyśmy katalog zawierający kandydata do wydania (release candidate) w wersji `testing', musielibyśmy, wydając tą wersję, zmienić jego nazwę na `stable', co mogłoby spowodować, że wszystkie serwery lustrzane FTP powtórnie pobierałyby całą dystrybucję (która jest dość spora).
Z drugiej strony, jeśli od początku nazywalibyśmy katalogi dystrybucyjne Debian-x.y, ludzie pomyśleliby, że dostępne jest wydanie Debiana x.y. (Kiedys tak się zdarzyło, gdy dostawca CD-ROM zbudował dystrybucję Debian 1.0 bazowaną na wersji rozwojowej pre-1.0. Dlatego pierwsze oficjalne wydanie było z numerkiem 1.1, a nie 1.0.)
Zatem nazwy katalogów dystrybucji w archiwum są determinowane przez ich nazwy kodowe, a nie ich status wydania (np. `slink'). Nazwy te zostają takie same podczas procesu rozwojowego i po wydaniu danej wersji; dowiązania symboliczne, które można w łatwy sposób zmienić, wskazują na aktualną stabilną dystrybucję. Dlatego prawdziwe katalogi dystrybucji używają nazw kodowych, podczas gdy dowiązania symboliczne dla stable, testing i unstable wskazują na określone katalogi wydań.
Różne archiwa oraz strony internetowe posiadają kilka dostępnych serwerów lustrzanych, aby odciążyć główne serwery. W rzeczywistości niektóre serwery główne nie są serwerami publicznymi, natomiast pierwszy poziom serwerów lustrzanych przejmuje i rozdziela obciążenie. Tym sposobem użytkownicy zawsze mają dostęp do serwerów lustrzanych i mogą ich używać, co pozwala Debianowi na lepsze rozłożenie przepustowości na kilka serwerów oraz sieci i umożliwia użytkownikom uniknięcie dobijania się do jednego serwera podstawowego. Zauważ, że serwery lustrzane pierwszego poziomu są aktualizowane tak często, jak tylko jest to możliwe, gdyż ich aktualizacja jest uaktywniana przez serwery podstawowe (nazywamy to ,,wymuszonym przekazywaniem kopii'' (,,push mirroring'')).
Wszystkie informacje na temat serwerów lustrzanych Debiana, włączając w to
listę odstępnych, publicznych serwerów FTP/HTTP, można znaleźć na http://www.debian.org/mirror/.
Ta użyteczna strona zwiera także informacje i narzędzia pomocne przy
uruchamianiu własnego serwera lustrzanego z dostępem publicznym lub
wewnętrznym.
Zauważ, że serwery lustrzane są utrzymywane przez osoby trzecie zainteresowane pomocą Debianowi. Zwykle dewloperzy nie posiadają kont na takich maszynach.
System Incoming (system pakietów przychodzących - przyjąłem oryginalne nazewnictwo tego systemu - przyp. tłum.) jest odpowiedzialny za odbieranie zaktualizowanych pakietów i ich instalację w archiwum Debiana. Składa się on z zestawu katalogów i skryptów, które zainstalowane są na ftp-master.debian.org oraz non-us.debian.org.
Pakiety przesyłane są przez wszystkich opiekunów do katalogu
unchecked (niesprawdzone). Katalog ten skanowany jest co 15 minut
przez skrypt katie, który weryfikuje integralność załadowanych
pakietów oraz ich podpisy cyfrowe. Jeśli pakiet zostanie uznany za gotowy do
instalacji, jest on przenoszony do katalogu accepted
(zaakceptowany). Jeżeli pakiet przesyłany jest do archiwum po raz pierwszy,
jest on przenoszony do katalogu new (nowe), gdzie oczekuje na
akceptację zarządcy ftp. Jeżeli pakiet zawiera pliki do ,,ręcznej''
instalacji, przenoszony jest on do katalogu byhand (ręcznie),
gdzie oczekuje na ręczną instalację przez zarządcę ftp. W innych przypadkach,
jeżeli rozpoznano jakiś błąd, pakiet jest odrzucany i przenoszony do katalogu
reject (odrzucone).
Gdy pakiet zostanie zaakceptowany, system wysyła do opiekuna list
potwierdzający, zamyka wszystkie błędy oznaczone jako usunięte w danej wersji i
automatyczne skrypty budujące (auto-builder) mogą zacząć rekompilację pakietu.
Od tej chwili pakiet jest publicznie dostępny na http://incoming.debian.org/ (dla
pakietów z archiwum non-US nie istnieje analogiczny URL) do czasu rzeczywistej
instalacji w archiwum Debiana. Dzieje się to tylko raz dziennie, po czym
pakiet jest usuwany z incoming i instalowany w pool razem ze wszystkimi innymi
pakietami. Gdy wszystkie inne aktualizacje (na przykład wygenerowanie plików
indeksowych Packages i Sources) zostaną wykonane,
wywoływany jest specjalny skrypt proszący wszystkie główne serwery lustrzane o
samoczynną aktualizację.
Oprogramowanie zarządzające archiwum wysyła także przesłany przez Ciebie plik
.changes, podpisany OpenPGP/GnuPG, na odpowiednie listy
dyskusyjne. Jeśli pakiet został wydany z polem Distribution:
ustawionym na `stable', wysyłane jest ogłoszenie na debian-changes@lists.debian.org.
Natomiast jeśli pakiet został wydany z polem Distribution:
ustawionym na `unstable' lub `experimental', ogłoszenie zostanie wysłane na
debian-devel-changes@lists.debian.org
Wszyscy deweloperzy Debiana mają prawo do zapisu w katalogu
unchecked, aby mogli przesyłać swoje pakiety; mają również dostęp
do katalogu reject, aby mogli usuwać błędnie przesłane pakiety lub
przenosić niektóre pliki z powrotem do katalogu unchecked. Prawo
do zapisu we wszystkich pozostałych katalogach ma tylko zarządca ftp, dlatego
nie możesz usunąć wysłanego pakietu, gdy ten został zaakceptowany.
Katalog unchecked posiada specjalny pokatalog DELAYED
(odroczone). Sam katalog podzielony jest na 9 mniejszych katalogów, nazwanych
od 1-day do 9-day. Pakiety przesłane do jednego z
tych katalogów będą przeniesione do `prawdziwego' katalogu unchecked po upływie
zadanej liczby dni, określonej przez nazwę danego katalogu. Wykonywane jest to
przez skrypt uruchamiany każdego dnia, który przenosi pakiety między
katalogami. Pakiety z katalogu ``1-day'' instalowane są w
unchecked, podczas gdy pozostałe są przenoszone do sąsiedniego
katalogu (na przykład pakiet z 5-day bedzie przeniesiony do
4-day). Ta właściwość jest szczególnie przydatna ludziom
przesyłającym poprawki do pakietów, których nie są opiekunami (czynność ta
zwana jest NMU - non-maintainer upload). W takim przypadku NMU dokonywane jest
do jednego z katalogów DELAYED/x-day. Tam pliki
oczekują określoną liczbę dni na reakcję opiekuna, który może w tym czasie
przesłać inne rozwiązanie problemu, jeśli nie satysfakcjonuje go poprawka z
NMU. Może też usunąć NMU.
Używanie tej możliwości może być łatwiejsze, jeśli zintegrujesz je z narzędziem
do przesyłania plików. Przykładowo, jeśli używasz dupload (zobacz
dupload, Rozdział A.5.1), możesz dodać do
swojego pliku konfiguracyjnego taki oto fragment:
$delay = ($ENV{DELAY} || 7);
$cfg{'delayed'} = {
fqdn => "ftp-master.debian.org",
login => "yourdebianlogin",
incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
dinstall_runs => 1,
method => "scpb"
};
Gdy wprowadzisz takie zmiany, dupload można będzie używać do
łatwego przesyłania pakietów do jednego z katalogów delayed:
DELAY=5 dupload --to delayed <changes-file>
Każdy pakiet posiada kilka dedykowanych stron internetowych. http://packages.debian.org/nazwa-pakietu wyświetla każdą wersję pakietu dostępnego w różnych dystrybucjach. Każda wersja odwołuje się do strony udostępniającej informacje takie jak opis pakietu, jego zależności i adres miejsca, z którego można go pobrać.
System śledzenia błędów kontroluje każdy błąd w danym pakiecie. Możesz obejrzeć błędy określonego pakietu na stronie http://bugs.debian.org/nazwa-pakietu.
madison
madison jest programem lini poleceń i dostępny jest na
ftp-master.debian.org oraz non-us.debian.org. Jako
jednyny parametr przyjmuje nazwę pakietu. Jako rezultat działania wyświetla
wersje pakietu dostępne dla poszczególnych kombinacji dystrybucji i
architektury. Poniższy przykład lepiej wyjaśni zasadę działania programu:
$ madison libdbd-mysql-perl
libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
W powyższym przykładzie zauważyć możesz, iż wersja z dystrybucji niestabilnej różni się od testowej; widać także, iż dla architektury alpha wykonano binarny NMU. Za każdym razem pakiet był rekompilowany na większość architektur.
System Śledzenia Pakietów (Package Tracking System - PTS) jest używanym do śledzenia aktywności pakietu źródłowego narzędziem wykorzystującym pocztę elektroniczną. Tak naprawdę oznacza to, że możesz otrzymywać te same listy, które dostaje opiekun, subskrybując po prostu dany pakiet w PTS.
Każdy list wysłany poprzez PTS jest klasyfikowany i kojarzony według jednego ze słów kluczowych podanych niżej. Pozwoli Ci to na wybranie tylko tych listów, które chcesz otrzymywać.
Domyślnie otrzymasz:
control@bugs.debian.org.
katie, gdy przesył pakietu źródłowego
zostanie zaakceptowany.
katie (takie jak różnice przy
nadpisywaniu dla sekcji i/lub pola priorytetu).
Możesz też zdecydować się na odbieranie dodatkowych informacji:
katie, gdy przesył pakietu
binarnego zostanie zaakceptowany. Innymi słowy, kiedykolwiek demon budujący
(build deamon) lub człowiek portujący przesyła Twój pakiet przeznaczony na inną
architekturę, otrzymasz list umożliwiający Ci śledzenie wyników kompilacji
Twojego pakietu na innych architekturach.
Możesz kontrolować swoje subskrypcje w PTS wysyłając różne polecenia na adres
pts@qa.debian.org.
control@bugs.debian.org
Gdy subskrybowałeś pakiet, będziesz otrzymywać listy wysyłane do
pakietźródłowy@packages.qa.debian.org. Listy te mają
dodatkowe nagłówki specjalne umożliwiające Ci filtrowanie listów w specjalnych
skrzynkach pocztowych (np. w procmail). Dodatkowymi nagłówkami
są: X-Loop, X-PTS-Package, X-PTS-Keyword
oraz X-Unsubscribe.
Poniżej znajduje się przykład dodatkowych nagłówków listu informującego o
przesyle pakietu źródłowego, na podstawie pakietu dpkg:
X-Loop: dpkg@packages.qa.debian.org
X-PTS-Package: dpkg
X-PTS-Keyword: upload-source
X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
Jeżeli używasz ogólnie dostępnego repezytorium CVS do zarządzania swoimi pakietami Debiana, możesz zechcieć przekazywać potwierdzenia polecenia cvs commit do systemu PTS, tak aby subskrybenci (oraz potencjalni współopiekunowie) mogli z bliska oglądać rozwój pakietu.
Gdy skonfigurujesz repezytorium CVS do generowania informacji potwierdzających cvs commit, musisz tylko upewnić się, że kopie wysyłane są na adresy pakietźródłowy_cvs@packages.qa.debian.org. Tylko ludzie akceptujący słowo kluczowe cvs będą otrzymywali te potwierdzenia.
System PTS posiada interfejs strony internetowej na http://packages.qa.debian.org/
który zawiera wiele informacji o każdym pakiecie źródłowym. Oferuje on wiele
użytecznych odsyłaczy (BTS, statystyki QA, informacje kontaktowe, status
tłumaczenia DDTP, logi buildd) i gromadzi wiele więcej informacji z różnych
miejsc (30 ostatnich wpisów changeloga, stan w dystrybucji testing, ...). Jest
to naprawdę pomocne narzędzie, jeśli chcesz być na bieżąco z określonym
pakietem źródłowym. Poza tym interfejs posiada formularz umożliwiający łatwą
subskrypcję w PTS przez pocztę elektroniczną.
Możesz bezpośrednio wejść na stronę związaną z określonym pakietem źródłowym wpisując adres URL w rodzaju http://packages.qa.debian.org/pakietźródłowy.
Interfejs ten został zaprojektowany jako portal dla rozwoju pakietów: możesz dodawać własne treści do strony internetowej swoich pakietów. Możesz dodać ,,informacje statyczne'' (nowości, które są niezmienne) oraz nowości w sekcji ,,najnowsze wieści''.
Nowości statyczne mogą być używane do wskazania:
Zwyczajne nowości mogą być używane do ogłaszania:
Oba rodzaje nowości są generowane w podobny sposób: musisz tylko wysłać list
albo na adres pts-static-news@qa.debian.org
albo na pts-news@qa.debian.org. List
powinien określać, z którym pakietem jest związany, poprzez umieszczenie nazwy
pakietu źródłowego w nagłówku listu X-PTS-Package lub
pseudo-nagłówku Package (tak, jak w przypadku raportu BTS). Jeśli
podano URL w nagłówku X-PTS-Url lub pseudo-nagłówku
Url, rezultatem jest odsyłacz do tego URL zamiast kompletnej
nowości.
Poniżej znajdują się przykłady prawidłowego listu użytego do wygenerowania nowości w PTS. Pierwszy z nich dodaje odsyłacz do interfejsu cvsweb debian-cd w sekcji ``informacja statyczna'':
From: Raphael Hertzog <hertzog@debian.org>
To: pts-static-news@qa.debian.org
Subject: Browse debian-cd CVS repository with cvsweb
Package: debian-cd
Url: http://cvs.debian.org/debian-cd/
Natomiast drugi list jest ogłoszeniem wysłanym na listę dyskusyjną, które zostało również przesłane do PTS, więc jest publikowane na stronie PTS danego pakietu. Zauważ, że użyto pola BCC, aby uniknąć omyłkowego wysłania do PTS.
From: Raphael Hertzog <hertzog@debian.org>
To: debian-gtk-gnome@lists.debian.org
Bcc: pts-news@qa.debian.org
Subject: Galeon 2.0 backported for woody
X-PTS-Package: galeon
Hello gnomers!
I'm glad to announce that galeon has been backported for woody. You'll find
everything here:
...
Pomyśl dwa razy, zanim dodasz nowość do PTS, ponieważ w przyszłości nie będziesz miał możliwości jej usunięcia ani edytowania. Jedyną rzeczą, którą możesz zrobić, jest wysłanie drugiej nowości, która dementuje informacje zawarte w poprzedniej.
Portal QA (zapewnienie jakości - quality assurance), dostępny pod adresem
http://qa.debian.org/developer.php,
wyświetla tabelę wszystkich pakietów pojedynczego dewelopera (włączając w to
pakiety, których jest współopiekowane). Tabela ta daje świetne podsumowanie
pakietów dewelopera: ilość błędów z określonym stopniem ważności, listę wersji
pakietów dostępnych w każdej dystrybucji, status dla dystrybucji testing i
wiele więcej, włączając w to odsyłacze do innych przydatnych informacji.
Dobrym pomysłem jest regularne przeglądanie swoich własnych danych, tak abyś nie zapomniał o otwartych błędach oraz żebyś nie zapomniał, za które pakiety jesteś odpowiedzialny.
Alioth jest dość nowym serwisem Debiana, opartym o nieco zmodyfikowaną wersję oprogramowania GForge (który ewoulował z SourceForge). Oprogramowanie to oferuje deweloperom dostęp do łatwych w użyciu narzędzi takich jak kontrolery błędów, menedżer łatek, menedżer zadań/projektów, usługi hostowania plików, listy dyskusyjne, repezytoria CVS itp. Wszystkie te narzędzia są zarządzane przez interfejs WWW.
W zamierzeniu ma on udostępniać narzędzia dla projektów wolnego oprogramowania wspieranych lub prowadzonych przez Debiana, ułatwiając zewnętrznym deweloperom udział w projektach zaczętych przez Debiana oraz pomagając projektom, których celem jest promocja Debiana lub jego pochodnych.
Więcej informacji można znaleźć pod adresem http://alioth.debian.org/.
Rozdział ten zawiera informacje związane z tworzeniem, umieszczaniem w archiwum, zarządzaniem pakietami, a także przenoszeniem ich na inne architektury.
Jeśli chcesz stworzyć nowy pakiet przeznaczony dla dystrybucji Debiana,
powinieneś najpierw sprawdzić listę Work-Needing and Prospective Packages
(WNPP) (Pakiety wymagające pracy i oczekiwane). Sprawdzanie listy
WNPP zagwarantuje, że nikt inny nie paczkuje danego oprogramowania i że Twoja
praca nie będzie dublowana. Więcej informacji znajdziesz na stronach internetowych
WNPP.
Zakładając iż nikt inny nie pracuje już nad Twoim przyszłym pakietem, musisz
zgłosić raport błędu (Zgłaszanie błędów, Rozdział
7.1) dotyczący pseudo-pakietu wnpp. Raport powinien zawierać
Twój plan tworzenia nowego pakietu włączając, ale nie ograniczając się
wyłącznie do tego, opis pakietu, zasady licencjonowania powstającego pakietu
oraz aktualny URL skąd można go pobrać.
W temacie wiadomości powinieneś wpisać ``ITP: foo -- krótki
opis'', zastępując foo nazwą nowego pakietu. Ważność raportu
błędu musi być ustawiona na wishlist. Jeśli czujesz taką potrzebę,
wyślij kopię na listę debian-devel@lists.debian.org
wstawiając jej adres w nagłówku wiadomości do X-Debbugs-CC: (nie
używaj w tym celu CC:, ponieważ ten sposób nie oznaczy numeru
błędu w temacie wiadomości).
Załącz proszę wpis Closes: bug#nnnnn w changelogu nowego pakietu aby raport błędu został automatycznie zamknięty gdy nowy pakiet będzie zainstalowany w archiwum (Kiedy błąd jest zamykany przez nowy przesył, Rozdział 5.8.4).
Oto kilka przyczyn dla których prosimy opiekunów o powiadamianie o swoich zamiarach:
Zmiany które poczyniłeś w pakiecie muszą być zapisane w pliku
debian/changelog. Powinny one zawierać zwięzły opis tego co i
dlaczego (jeśli są jakieś wątpliwości) zostało zmienione, oraz informację czy
został poprawiony jakiś błąd. Poza tym zapisuje datę skompletowania pakietu.
Plik ten będzie zainstalowany w
/usr/share/doc/pakiet/changelog.Debian.gz, lub
/usr/share/doc/pakiet/changelog.gz w przypadku pakietów
wewnętrznych.
Plik debian/changelog dostosowany jest do określonej struktury z
kilkoma różnymi polami. Jedno z pól informacyjnych, distribution,
opisane jest w Dobieranie dystrybucji, Rozdział
5.5. Więcej informacji na temat struktury tego pliku mozna znaleźć w
sekcji Polityki Debiana zatytułowanej
"debian/changelog".
Wpisy w changelogu mogą być używane do automatycznego zamykania błędów Debiana, gdy pakiet zostaje zainstalowany w archiwum. Zobacz Kiedy błąd jest zamykany przez nowy przesył, Rozdział 5.8.4.
Przyjęło się, że wpis w changelogu znakujący pakiet który zawiera nową zewnętrzną wersję oprogramowania wygląda następująco:
* new upstream version
Istnieją narzędzia wspomagające tworzenie wpisów i zamykanie sekcji pliku
changelog przed wydaniem — zobacz devscripts, Rozdział A.6.1 i dpkg-dev-el, Rozdział A.6.6.
Zobacz także Najlepsze zwyczaje dla
debian/changelog, Rozdział 6.3.
Zanim umieścisz swój pakiet w archiwum, powinieneś wykonać na nim podstawowe testy. Jako miniumum, powinieneś wykonać następujące rzeczy (będziesz potrzebować starszej wersji tego samego pakietu Debiana):
lintian na tym pakiecie. Możesz uruchomić
lintian następująco: lintian -v
pakiet-wersja.changes. Polecenie to sprawdzi zarówno źródła
pakietu jak i jego binarną wersję. Jeśli nie rozumiesz generowanych przez
lintian komunikatów, spróbuj dodać opcję -i, która
spowoduje, że lintian wyświetli szerszy opis problemu.
Zazwyczaj pakiet nie powinien być umieszczany w archiwum jeśli lintian pokazuje jakieś błędy (rozpoczynać się one będą literą E).
W celu uzyskania dodatkowych informacji o programie lintian,
zobacz lintian, Rozdział A.2.1.
debdiff, Rozdział
A.2.3 w celu analizy zmian w starszej wersji, jeśli takowa istnieje.
postrm i
prerm.
Istnieją dwa rodzaje pakietów źródłowych Debiana:
W przypadku wewnętrznych pakietów, pakiet źródłowy posiada debianowy plik kontolny źródła (.dsc) i archiwum (.tar.gz). Zewnętrzny pakiet źródłowy zawiera debianowy plik kontrolny źródła, oryginalne spakowane archiwum (.orig.tar.gz) i łatkę Debiana (.diff.gz).
To czy pakiet jest wewnętrzny czy nie, jest definiowane podczas jego budowania
za pomocą dpkg-buildpackage(1). Pozostała część tego rozdziału
związana jest wyłącznie z pakietami zewnętrznymi.
Gdy wersja jest pierwszy raz umieszczena w archiwum odpowiadająca za określoną
wersję zewnętrzną, jej oryginalne archiwum źródłowe tar powinno być załadowane
i zawarte w pliku .changes. Następnie dokładnie ten sam plik
archiwum tar powinien być użyty do budowania nowych plików diff i
.dsc, bez potrzeby powtórnego zapisywania do archiwum.
Domyślnie dpkg-genchanges oraz dpkg-buildpackage
włączą oryginalny plik tar ze źródłem wtedy i tylko wtedy gdy debianowa wersja
źródła posiada numer 0 lub 1, wskazując nową zewnętrzna wersję. To zachowanie
można modyfikować za pomocą opcji -sa jeśli ma być zawsze
włączane, lub -sd jeżeli nie ma być umieszczane.
Jeżeli do archiwum nie jest wysyłane oryginalne źródło, oryginalny plik
źródłowy tar użyty przez dpkg-source podczas tworzenia pliku
.dsc i różnic musi być identyczny, co do bajtu, z tym
znajdującym się już w archiwum.
Każde umieszczenie pakietu w archiwum potrzebuje określenia dla jakiej
dystrybucji jest on przeznaczony. Proces budowania pakietu pobiera tę
informację z pierwszej linii pliku debian/changelog i wstawia ją
do pola Distribution w pliku .changes.
Pole to może zawierać kilka wartości: `stable', `unstable' `testing-proposed-updates' i `experimental'. Zazwyczaj pakiety są przesyłane do unstable.
Właściwie istnieją jeszcze dwie inne dystrybucje: `stable-security' i `testing-security', ale poczytaj Obsługa błędów związanych z bezpieczeńswtem, Rozdział 5.8.5 jeśli chcesz dowiedzieć się o nich więcej.
Technicznie możliwe jest wysłanie pakietu dla kilku dystrybucji w tym samym momencie, lecz zazwyczaj nie ma sensu wykorzystywać tej możliwości, ponieważ zależności pakietu mogą się różnić między dystrybucjami. W szczególności, najmniejszego sensu nie ma łączenie dystrybucji experimental z jakąkolwiek inną (zobacz Dystrybucja eksperymentalna, Rozdział 4.6.4.3).
Umieszczanie w stable oznacza, że pakiet będzie wstawiony do katalogu
archiwum Debiana stable-proposed-updates w celu późniejszego jego
przetestowania zanim rzeczywiście będzie on właczony do dystrybucji
stable.
Przy ładowaniu do dystrybucji stable powinna zostać zachowana szczególna ostrożność. Przede wszystkim pakiet tylko wtedy powinien być umieszczany w dystrybucji stabilnej, gdy usuwa jeden z następujących problemów:
W przeszłości umieszczanie pakietu w dystrybucji stable było używane
również w przypadku problemów bezpieczeństwa. Niemniej jednak praktyka ta jest
potępiana, ponieważ pakiety używane w łatach bezpieczeństwa Debiana są
automatycznie kopiowane do określonego archiwum proposed-updates,
kiedy taka jest publikowana. Zobacz Obsługa błędów
związanych z bezpieczeńswtem, Rozdział 5.8.5, gdzie zajdziesz szczegółowe
informacje na temat obchodzenia się z problemami bezpieczeństwa.
Odradza się wprowadzanie w pakiecie jakichkolwiek zmian, które nie są niezbędne, ponieważ nawet proste poprawki potrafią powodować błędy w przyszłości.
Pakiety umieszczane w archiwum stable muszą być kompilowane na stabilnej dystrybucji, jako że ich zależności są ograniczone do bibliotek (i innych pakietów) dostępnych w wersji stable; na przykład pakiet umieszczony w archiwum stable, który zależny jest od pakietu bibliotek istniejących tylko w dystrybucji unstable będzie odrzucany. Wykonywanie zmian w zależnościach innych pakietów (poprzez grzebanie w plikach Provides czy shlibs) może skutkować niemożnością ich zainstalowania, dlatego jest stanowczo odradzane.
Zespół Wydający (który można złapać pod adresem debian-release@lists.debian.org)
regularnie ocenia pliki w stable-proposed-updates i decyduje czy Twój
pakiet może być włączony do dystrybucji stabilnej. Proszę więc o
jasne (i szczegółowe, jeśli istnieje taka potrzeba) wpisy w changelogu pakietu
przeznaczonego dla wersji stable, ponieważ w przeciwnym wypadku nie
zostanie włączony do dystrybucji.
Dystrybucja testowa ,,karmiona'' jest pakietami z wersji niestabilnej zgodnie z zasadami wyjaśnionymi w Więcej informacji o dystrybucji testowej, Rozdział 4.6.4.2. Jednakże opiekun wydania może zatrzymać skrypt testujący kiedy chce zamrozić dystrybucję. W takim przypadku, będziesz chciał umieścić pakiet w testing-proposed-updates co pozwala na eliminowanie błędów w pakietach podczas zamrożenia dystrybucji.
Pamiętaj, że pakiety tam umieszczane nie są automatycznie przetwarzane, muszą
one przejść bezpośrednio przez ręce opiekuna dystrybucji. Tak więc lepiej mieć
dobrą podstawę do umieszczania ich w tym miejscu. Aby dowiedzieć się co jest
dobrą przyczyną dla opiekuna, powinieneś czytać instrukcje regularnie
umieszczane przez niego na liście debian-devel-announce@lists.debian.org.
Nie powinieneś umieszczać pakietów w testing-proposed-updates jeśli możesz zaktualizować je bezpośrednio w unstable. Jeżeli nie możesz (gdyż masz na przykład nowszą, rozwojową wersję w unstable), użyj tej dystrybucji ale zalecane jest najpierw poproszenie o zgodę opiekuna wydania.
Aby przesłać pakiet potrzebujesz osobistego konta na
ftp-master.debian.org, które powinieneś posiadać jako oficjalny
opiekun. Jeżeli do przesyłania plików używasz scp lub
rsync, umieszczaj pakiety w katalogu
/org/ftp.debian.org/incoming/; jeśli używasz anonimowego FTP,
umieść pakiety w katalogu /pub/UploadQueue/.
Jeżeli chcesz używać możliwości opisanych w Odraczanie pakietów przychodzących, Rozdział 4.8.1, będziesz musiał przesyłać pakiety do ftp-master. Jest to jedyny punkt przesyłu który obsługuje odraczanie pakietów.
Zauważ proszę, że plik ze zmianami powinieneś przesłać na końcu. W przeciwnym
razie twój transfer może zostać odrzucony, ponieważ oprogramowanie nadzorujące
archiwum przetworzy plik ze zmianami i zobaczy że nie wszystkie pliki zostały
przesłane. Jeśli nie chcesz męczyć się z przesyłaniem pliku zmian jako
ostatniego, możesz po prostu skopiować pliki do tymczasowego katalogu na
ftp-master a potem przenieść je do katalogu
/org/ftp.debian.org/incoming/.
Uwaga: Nie przesyłaj do ftp-master pakietów
kryptograficznych należących do contrib lub non-free. Tego
rodzaju oprogramowanie powinno być umieszczane w non-us (zobacz Przesyłanie do non-US, Rozdział
5.6.2). Ponadto pakiety zawierające kod którego dystrybucja jest
ograniczona przez rząd Stanów Zjednoczonych prawami patentowymi, nie mogą być
umieszczane w ftp-master; w tym przypadku pakiety mogą być w
dalszym ciągu przesyłane do katalogu non-US/non-free (jest w
non-free z powodów dystrybucyjnych a nie z powodu licencji na oprogramowanie).
Jeśli nie możesz załadować tego na ftp-master, to nie możesz też
przesłać go do innych kolejek przesyłu na chiark lub
erlangen. Jeśli nie jesteś pewien czy Twój pakiet zalicza się do
programów opatentowanych przez USA lub kryptograficznych, wyślij list z
pytaniem na debian-devel@lists.debian.org.
Pomocne mogą okazać się również narzędzia dupload, Rozdział A.5.1 lub dput, Rozdział A.5.2. Te poręczne programy
pomagają w automatyzacji procesu umieszczania pakietów w Debianie.
Po przesłaniu swojego pakietu, możesz sprawdzić jak zostanie on przetworzony
przez oprogramowanie nadzorujące archiwum poprzez uruchomienie
dinstall na Twoim pliku zmian:
dinstall -n foo.changes
Zauważ, że dput może to zrobić za Ciebie automatycznie.
Jak omawialiśmy powyżej, oprogramowanie podlegające ograniczeniom eksportu nie
powinno być umieszczane na ftp-master. Zamiast tego, prześlij
pakiet do non-us.debian.org, wstawiając pliki do katalogu
/org/non-us.debian.org/incoming/ (raz jeszcze przypominam, że dupload, Rozdział A.5.1 i dput, Rozdział A.5.2 mogą to zrobić za Ciebie,
jeśli je prawidłowo wywołasz). Domyślnie możesz użyć tej samej nazwy
użytkownika i hasła które działa na ftp-master. Jeżeli do
przesyłania używasz anonimowego FTP, umieść pliki w katalogu /pub/UploadQueue/.
Możesz sprawdzić załadowane pliki tym samym sposobem który jest używany w ftp-master:
dinstall -n foo.changes
Zauważ, że rezydenci i obywatele USA podlegają ograniczeniom eksportu oprogramowania kryptograficznego. W momencie powstawania tego tekstu obywatele USA są dopuszczeni do eksportu niektórych programów kryptograficznych zgodnie z zasadami powiadamiania Departamenu Handlu USA. Niemniej jednak, ograniczenie to zostało zniesione dla oprogramowania które jest już dostępne poza granicami USA. Dlatego każdy program kryptograficzny należący do sekcji main archiwum Debiana, który nie jest zależny od jakiegokolwiek pakietu spoza main (tzn. nie zależy od czegokolwiek w non-US/main), może być umieszczany w ftp-master lub jego kolejkach, w opisany wyżej sposób.
Polityka Debiana nie uniemożliwia przesyłania pakietów do non-US przez rezydentów lub obywateli USA, ale powinno być to wykonywane z uwagą. Zalecane jest aby deweloperzy podjęli wszelkie niezbędne kroki w celu zapewnienia że przesyłając pliki do non-US nie naruszają aktualnie obowiązującego prawa USA, włączając w to konsultacje z prawnikiem.
W przypadku pakietów w non-US/main, non-US/contrib,
deweloperzy powinni przynajmniej zapoznać się z procedurami
rządu USA. Opiekunowie pakietów z non-US/non-free powinni
dodatkowo poczytać o zasadach zgłaszania do
eksportu oprogramowania non-free.
Rozdział ten pełni wyłącznie funkcję informacyjną i nie stanowi porady prawnej. Raz jeszcze więc zalecamy, aby obywatele i rezydenci USA skonsultowali się z prawnikiem zanim umieszczą plik w non-US.
Jeśli masz wolne połączenie sieciowe do ftp-master, istnieją
alternatywne rozwiązania. Jednym z nich jest wrzucanie plików do
Incoming poprzez kolejkę przesyłania w Europie na
chiark. Więcej szczegółów po połaczeniu się z ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload.
Uwaga: Nie umieszczaj pakietów zawierających oprogramowanie podlegające ograniczeniom eksportu przez rząd Stanów Zjednoczonych do kolejki na chiark. Ponieważ kolejka ta przechodzi na ftp-master, przepis umieszczony w Przesyłanie do ftp-master, Rozdział 5.6.1 stosuje się również tutaj.
Program dupload obsługuje przesyłanie plików do
chiark; zapoznaj się ze szczegółami w dokumentacji programu.
Jeszcze jedna kolejka przesyłu dostępna jest w Niemczech: załaduj po prostu
pliki używająć anonimowego FTP na ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/.
Przesył musi być kompletnym transferem Debiana, takim jaki wstawiłbyś do
Incoming na ftp-master, tzn. pliki
.changes razem z innymi wymienionymi w .changes.
Demon kolejkowania sprawdza poza tym czy plik .changes jest
prawidłowo podpisany kluczem GnuPG lub OpenPGP przez dewelopera Debiana, aby
żadne podrobione pliki nie dostały się tą drogą na ftp-master.
Proszę poza tym upewnić się, że pole Maintainer w
.changes zawiera Twój adres poczty elektronicznej. Adres
ten używany jest do wszystkich odpowiedzi, tak samo jak na
ftp-master.
Nie ma potrzeby przenoszenia swoich plików do drugiego katalogu po ich przesłaniu, tak jak na chiark. W każdym przypadku powinieneś także otrzymać od demona kolejki list wyjaśniający co stało się z twoim przesyłem. Zwykle pakiet powinien być przeniesiony do ftp-master, ale w przypadku błędów, też jesteś o tym informowany.
Uwaga: Nie umieszczaj pakietów zawierających oprogramowanie o ograniczonym przez rząd Stanów Zjednoczonych eksporcie do kolejki na erlangen; Ponieważ kolejka ta przechodzi na ftp-master, przepis umieszczony w Przesyłanie do ftp-master, Rozdział 5.6.1 stosuje się również tutaj.
Program dupload obsługuje przesyłanie plików do
erlangen; zapoznaj się ze szczegółami w dokumentacji programu.
Inna dostępna kolejka przesyłu zlokalizowana jest w USA i jest dobrym archiwum
w przypadku problemów z dostaniem się na ftp-master. Możesz
przesyłać pliki, tak samo jak do erlangen na ftp://samosa.debian.org/pub/UploadQueue/.
Kolejka przesyłu dostępna jest też w Japoni; umieść pliki korzystając z
anonimowego FTP na ftp://master.debian.or.jp/pub/Incoming/upload/.
Opiekunowie archiwum Debiana są odpowiedzialni za obsługę umieszczania
pakietów. W dużej części obsługa ta wykonywana jest automatycznie w codziennym
cyklu przez narzędzia utrzymujące archiwum, katie. Konkretnie,
automatyczna obsługa wykonywana jest dla aktualizacji istniejących pakietów do
dystrybucji `unstable'. W innych przypadkach, szczególnie przy nowych
pakietach, wstawianie przesłanych pakietów do dystrybucji jest wykonywane
ręcznie. Kiedy przesyłanie wykonywane jest ręcznie, może się zdarzyć, że
zmiana w archiwum trwa nawet miesiąc. Proszę, bądź cierpliwy.
W każdym przypadku otrzymasz list informujący, że pakiet został dodany do archiwum, w którym będzie także zasygnalizowane jakie błędy zostaną wyeliminowane przez ten przesył. Proszę o dokładne zapoznanie sie z tym listem i sprawdzenie czy nie ujawnił się żaden z błędów które zamykałeś.
Potwierdzenie instalacji zawiera także informacje o tym, do jakiej sekcji został zakwalifikowany pakiet. Jeśli istnieją jakieś niejasności otrzymasz osobny list informujący o zaistniałej sytuacji. Poczytaj o tym niżej.
Zauważ także, że jeśli umieszczałeś pakiet za pomocą kolejek, demon kolejkowania również wyśle Ci powiadomienie pocztą elektroniczną.
Pola Section i Priority pliku
debian/control nie precyzują w rzeczywistości w którym miejscu
archiwum zostanie umieszczony plik, ani też jego priorytetu. Nad zachowaniem
ogólnej integralności archiwum czuwają opiekunowie archiwum, którzy kontrolują
te pola. Wartości w pliku debian/control są w zasadzie tylko
wskazówkami.
Opiekunowie archiwum kontrolują kanoniczne sekcje i priorytety dla pakietów w
pliku override (override file). Jeśli istnieją jakieś różnice
pomiędzy plikiem override a polami pakietu wypełnionymi w
debian/control, otrzymasz list informujący o rozbieżnościach w
trakcie instalowania pakietu w archiwum. Możesz wtedy albo poprawić swój plik
debian/control przeznaczony do następnego przesyłu, albo możesz
zechcieć zrobić zmiany w pliku override.
Aby zmienić sekcję do której rzeczywiście wstawiany jest pakiet, musisz
najpierw upewnić się, że plik debian/control Twojego pakietu jest
poprawny. Następnie wyślij list na override-change@debian.org
lub wypełnij raport błędu dla pakietu ftp.debian.org informując,
iż sekcja lub priorytet Twojego pakietu będzie zmieniony ze starego na nowy.
Upewnij się, iż wyjaśniłeś przyczynę zmiany.
Aby poznać więcej informacji o pliku override, zobacz
dpkg-scanpackages(8) oraz http://www.debian.org/Bugs/Developer#maintincorrect.
Zauważ przy tym, że określenie ,,sekcja'' jest używane do rozdzielenia pakietów według ich licencji, np. main, contrib i non-free. Zostało to opisane w innym rozdziale, Archiwum Debiana, Rozdział 4.6.
Każdy deweloper musi potrafić korzystać z debianowego systemu śledzenia błędów.
Zawiera się w tym wiedza o tym jak prawidłowo raportować błąd (zobacz Zgłaszanie błędów, Rozdział 7.1), jak je aktualizować
i przeklasyfikowywać, a także jak je obsługiwać i zamykać.
Interesujące dla deweloperów właściwości systemu śledzenia błędów opisano w
dokumentacji BTS dla
deweloperów. Zawiera ona informacje o zamykaniu błędów, wysyłaniu
uzupełnionych wiadomości, przyporządkowywaniu ważności i znaczników, oznaczaniu
błędów jako przekazane i o innych tematach.
Operacje takie jak zmiana przyporządkowania błędu na inne pakiety, scalania
różnych raportów o błędach powiązanych z tym samym tematem, lub powtórnego
otwarcia błędów przedwcześnie zamkniętych, są obsługiwane przez tak zwany
pocztowy serwer kontrolujący. Wszystkie dostępne polecenia na tym serwerze
zostały opisane w dokumentacji serwera
kontrolnego BTS.
Jeśli chcesz być dobrym opiekunem, powinieneś regularnie sprawdzać system śledzenia błędów (BTS) dla
swoich pakietów. BTS zawiera wszystkie otwarte błędy w Twoich pakietach.
Możesz sprawdzać je otwierając stronę:
http://bugs.debian.org/twój_login@debian.org.
Opiekunowie kontaktują się z BTS poprzez pocztę elektroniczną na
bugs.debian.org. Dokumentację opisującą dostępne polecenia można
znaleźć na http://www.debian.org/Bugs/, lub
jeśli masz zainstalowany pakiet doc-debian, możesz zerknąć do
lokalnych plików /usr/share/doc/debian/bug-*.
Dla niektórych użyteczne mogą być regularne raporty o otwartych błędach. Możesz dopisać następującą linijkę do pliku cron, jeśli chcesz otrzymywać cotygodniowy list podsumowujący wszystkie otwarte błędy dotyczące Twoich pakietów:
# proszę o tygodniowy raport błędów w moich pakietach
0 17 * * fri echo "index maint address" | mail request@bugs.debian.org
Zamień address na swój oficjalny debianowy adres opiekuna.
Gdy odpowiadasz na błędy upewnij się, że cała dyskusja wysyłana jest zarówno do
oryginalnych zgłaszających błąd jak i do samego błędu (tzn. 123@bugs.debian.org). Jeśli
piszesz nowy list, a nie pamiętasz adresu zgłaszającego, możesz użyć adresu
123-submitter@bugs.debian.org
aby wysłać go do zgłaszającego oraz aby został on zapisany w logu
błędu (oznacza to, że nie musisz pamiętać o wysłaniu kopii listu do 123@bugs.debian.org).
Jeśli otrzymałeś błąd który mówi "FTBFS", znaczy to "Błąd w budowaniu ze źródła". Porterzy często używają tego skrótu.
Kiedy uporałeś się z raportem błędu (np. wyeliminowałeś go), oznacz go jako
done (zamknij go) wysyłając wiadomość wyjaśniającą do 123-done@bugs.debian.org.
Jeśli usunąłeś problem zmieniając i umieszczając w archiwum pakiet, możesz
automatycznie zamknąć błąd wedle opisu w Kiedy błąd
jest zamykany przez nowy przesył, Rozdział 5.8.4.
Nigdy nie powinieneś zamykać błędu wysyłając polecenie
close serwera błędów do control@bugs.debian.org.
Jeśli tak zrobisz, oryginalny zagłaszający nie otrzyma żadnej informacji o tym,
dlaczego błąd został zamknięty.
Jako opiekun pakietów, często znajdował będziesz błędy w obcych pakietach, albo
w Twoich pakietach zgłaszane będą błędy, które w rzeczywistości są błędami w
innych pakietach. Interesujące dla deweloperów właściwości systemu śledzenia
błędów opisano w dokumentacji BTS dla
deweloperów. Operacje takie jak zmiana przydzielenia, łączenie, czy
oznaczanie raportów błędu opisano w dokumentacji serwera kontroli
BTS. Rozdział ten zawiera trochę wytycznych pomocnych przy
zarządzaniu swoimi błędami, opartych o wspólne doświadczenia deweloperów
Debiana.
Rejestrowanie błędów znalezionych w innych pakietach jest jednym z "obywatelskich obowiązków" opiekunów, więcej szczegółów znajdziesz w Zgłaszanie błędów, Rozdział 7.1. Niemniej jednak, jeszcze ważniejszą sprawą jest obługiwanie błędów we własnych pakietach.
Poniżej jest lista kroków, której możesz się trzymać zajmując się zgłoszeniem błędu:
Jeśli osoba zgłaszająca błąd nie zgadza się z Twoją decyzją zamknięcia błędu, może ona powtórnie go otworzyć, do czasu znalezienia kompromisu w sprawie, jak go zamknąć. Jeśli nic nie odnajdziesz, być moż