sinnvolle sources.list für Entwickler

[zucki]

Moin!

Bisweilen hab ich immer drumherum gebastelt und irgendwie meine sources.list zusammengestöpselt sodass alles funktionierte. Der Rest war und ist mir eigentlich egal. - Ob OpenSource oder nicht, Hauptsache ich kann mit arbeiten.
Das geht solange die Pakete aktuell genug sind und ich nicht selber kompilieren muss.

Code: Alles auswählen

% more /etc/apt/sources.list

# deb cdrom:[Debian GNU/Linux 5.0.3 _Lenny_ - Official amd64 CD Binary-1 20090905-11:02]/ lenny main 
# deb cdrom:[Debian GNU/Linux 5.0.3 _Lenny_ - Official amd64 CD Binary-1 20090905-11:02]/ lenny main 

deb http://security.debian.org/ lenny/updates main  
# Line commented out by installer because it failed to verify:
# deb-src http://security.debian.org/ lenny/updates main 

deb http://volatile.debian.org/debian-volatile/ lenny/volatile main  
# Line commented out by installer because it failed to verify:
# deb-src http://volatile.debian.org/debian-volatile/ lenny/volatile main 

deb http://security.debian.org/ stable/updates main contrib non-free 

# -> unstable
# deb http://ftp2.de.debian.org/ unstable main contrib non-free  
deb http://ftp.de.debian.org/debian/ unstable main contrib non-free 
deb http://ftp.de.debian.org/debian lenny main

# grml stuff
deb http://deb.grml.org/ grml-unstable main 

# Multimedia
deb http://www.debian-multimedia.org/ unstable main 

# backports
deb http://www.backports.org/debian/ etch-backports main 

# unoffz
deb http://unofficial.debian-maintainers.org/ sid/snapshots main contrib non-free restricted 

Nun hatte ich gestern mal wieder so ein Erlebnis, in dem sich die Debian Maintainer gegen Kompatibelität für RFC Compliance entschieden haben (dieser schöne Thread in der devel-Mailinglist klärt auf: hier.). Das ließ erst mal keine Java Applikation mehr IPv4 Sockets benutzen und man kann sich vorstellen wie viel Spaß es macht eine ganze IDE auf dieses Problem hin zu debuggen... bis man herausfindet, dass man doch lieber in Testing gehen sollte - nehme ich an?

Was will man als Entwickler da haben, was konservativ genug ist, sodass alles läuft und was aktuell genug ist. Nutzt man da evtl. apt-pinning? Letzten Endes suche ich nur eine Lösung, die mir nicht nach jedem Update neue Steine in den Weg legt. Ohne, dass ich vorher jedes Changelog durchlesen muss.

Code: Alles auswählen

% sudo apt-get install eclipse-pydev-gcj

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  eclipse-pydev-gcj: Depends: eclipse-platform-gcj but it is not going to be installed
E: Broken packages

Willkommen in der Paket Hölle.


Danke .
Zucki

[novalix]

Hallo,

Du fragst, ob apt-pinning eine sinnvolle Option wäre. Bei der sources.list, die Du gepostet hast, ist es die einzige Möglichkeit, das System kontrollierbar und einigermaßen konsistent zu halten.
Falls Du nicht zumindest die Konfigurationsoption "Default Release" auf "stable" gesetzt hast (pinning kann das granularer), hast Du nach dem ersten Upgrade sowieso kein Stablesystem mehr und kannst die dementsprechenden Paketquellen (inkl. Sicherheitsupdates) gleich ganz aus der sources.list entfernen.
Kurz: Sobald Du Testing- oder gar Unstablequellen in die sources.list aufnimmst und diese nicht explizit auf eine niedrige Priorität herunter pinnst, dann hast Du über kurz oder lang ein Testing- bzw. Unstableinstallation. Der Paketmanager installiert per Voreinstellung die "neueste" vorhandene Paketversion.

Unstable heisst aus gutem Grund so. In diesem Zweig können die Maintainer neue Paketversionen und neue Konfigurationsoptionen ausprobieren. Diese Möglichkeit des Experimentierens ist eminent wichtig, um langfristig ein neues stabiles System zu entwickeln. Dabei geschieht es natürlich immer wieder, dass eine neue Einstellung oder ein neues Feature bestehende Systeme negativ beeinflusst; ein Bug.

Trotzdem kann man auch mit Unstablepaketen produktiv arbeiten. Dazu sollte man allerdings neben einer vernünftigen Pinningstrategie auch noch solche Tools wie apt-listbugs und apt-listchanges einsetzen. Dann kann man auch die Changelogs lesen. Nicht alle sondern nur die, der zu aktualisierenden Pakete.

Groetjes, niels

[zucki]

Joahr, das fliegt einem so ziemlich schnell um die Ohren.


apt-pinning schaut auf den ersten Blick ziemlich einfach aus: http://jaqque.sbih.org/kplug/apt-pinning.html

Auf den zweiten Blick frage ich mich wie man hier mit den inoffiziellen Pakages und den backports umgehe. Zudem löst es nicht mein Problem mit eclipse-pydev-gcj - denn auch mit der Konfig aus dem apt-pinning Tutorial ändert sich die Fehlermeldung nicht. *hmmh*

[bmario]

Also ich würde an deiner Stelle ein reines Stable System installieren und nicht die sources.list so vollstopfen.

Dann brauchste das sun-jdk.

Dann ziehst du dir die akuelle Eclipse direkt von Eclipse.org und entpackst die entweder in deinem Home Verzeichnis, oder nach /opt/

Und fertig. Dann kannst du Eclipse über den integrierten Updater aktuell halten und alle möglichen AddOn's dafür installieren.
Genauso NetBeans, wenn du es benutzt.

mario