Nico
former person of interest
|
Also ich bin es gewohnt diverse Pakete/Tools - zb pidgin, php,apache, gcc, cmake, diverse lib deps und den kernel neu zu kompilieren, da mir die Version der Distro oft zu alt ist. Heute ist das ja keine hexerei mehr. Wie geht es euch mit der Aktualität der Pakete bei eurer Distro-of-Choice? Was kompilierst du in neuerer Version?
|
t3mp
I Love Gasoline
|
//Gentoo User here
Der Kernel wird immer selbst kompiliert, das ist bei Gentoo einfach so. Ist aber auch zwischen Major Bumps ganz einfach, mittels make oldconfig die paar neuen config options zu (de)selektieren.
Overlays decken eigentlich alles Experimentelle ab (wie z.B. momentan gerade qt-5.3.0 und kde-frameworks-5/plasma-workspaces-2).
Geht mir ein simpler Version Bump nicht schnell genug, erstell (meistens nur copy-paste) ich die notwendige ebuild selbst, teste, und erstell falls nötig einen bug report mit einer diff der nötigen Änderungen. Das bedeutet, eine aktuellere Version als jene in Portage wird verwendet, trotzdem befindet sie sich nahtlos mittels lokalem Overlay im Paketmanagement.
Bearbeitet von t3mp am 15.05.2014, 20:13
|
bsox
Schwarze Socke
|
So wenig wie möglich. Ich will mich einfach nicht mehr um security updates selber kümmern müssen und dazu sämtliche Repositories im Auge behalten. Da verlasse ich mich der Faulheit halber auf die Debian Maintainer.
Linux verwende ich fast ausschließlich auf Servern und da brauche ich kein bleeding edge System. Im Gegenteil, permanente Updates gehen mir da eher am Nerv, besonders Kernelgeschichten die einen Reboot nach sich ziehen. Auf einer Workstation würde es wahrscheinlich etwas anders aussehen.
Gentoo war lässig und durch die exzellente Dokumentation ich hab' dabei viel gelernt, aber das ewige Kompilieren auf meinem 486er (oder wars schon ein Pentium 2?) waren dann auf die Dauer doch nicht so prikelnd.
|
-=Willi=-
The Emperor protects
|
Auf Servern nix. Am Desktop nur hin und wieder die neusten Version irgendwelcher Spielereien dies halt grad nur auf github.com als Source gibt (z. B. neulich erst Final Term). Was mich dann halt am meisten stört ist dass selbstkompilierte Software aus dem Paketmanager fällt und nicht damit verwaltet/geupdatet/entfernt werden kann. Deshalb lass ich bei selbstkompilierten Dingen auch immer das `make install` aus, sondern betreibs immer von dort, wo ich es kompiliert hab. Das macht mich ganz unwohl wenn ich an irgendwelche Files u. Binaries denk, die ich selbst auf /etc, /usr usw. verstreut hab (bzw. make verstreut hat) . Ja ich weiß, man könnts auch selbst paketieren aber...such work, much no care .
|
JDK
Oberwortwart
|
Ich kompiliere eigentlich nur OpenCV (Debian inkludiert nicht alle Algorithmen)...vlt hab ich noch NDISWrapper selber kompiliert...weiß ich nimmer. Abgesehen von meinen eigenen Programmen halt.
|
davebastard
Vinyl-Sammler
|
so wenig wie möglich, sowohl auf server als auch desktop.
am desktop verwend ich halt den debian "testing" zweig statt "stable". die pakete da drinnen sind mir aktuell genug. momentan hab ich auch keine anderen repositories als die von debian eingetragen.
selbstkompiliertes fällt mir im augenblick auch nichts mehr ein früher war da schon einiges. ah doch, für meine gps uhr musste ich mal was kompilieren. exotische sachen halt die es nicht in die repositories schaffen...
find es auch viel gscheiter wenn ich mich ned selbst um updates kümmern muss.
|
issue
Rock and Stone, brother!
|
Je nach Lust und Laune, bzw Experimentierfreudigkeit. Wenn es ein Patch noch nicht in die Repos geschafft hat (selten) oder ich etwas brauche das nicht in den Repos ist, dann wird gcc bemueht. Relativ regelmaessig baue ich wine, kernel bau ich, seit es vom -ck patchset Pakete fuer Arch gibt, auch nicht mehr selber.
Bearbeitet von issue am 15.05.2014, 20:24
|
COLOSSUS
AdministratorGNUltra
|
Immer wenn ich was selbst kompiliere, dann bau ich daraus ein Paket, und installiere das via Paketmanager. Das sollte sich uebrigens jeder dringend angewoehnen, der das ab und zu macht. Dazu reicht es mit Debian meist, das aktuelle experimental/unstable-Paket (oder etwas, das rc-buggy ist, mit dessen spezifischen Defekten ich aber durchaus leben kann) auf mein Release (wheezy) backzuporten. Die notwendigen build-time dependencies kann aptitude automatisch ermitteln und installieren. Wer sich sein Hauptsystem nicht mit den vielen -dev-Paketen "zumuellen" will, kann das alles in einem chroot auf dem selben Host erledigen.
Beruflich sieht es so aus, dass wir einen Buildserver und ein eigenes Repository haben, in dem wir Dinge packagen, die wir zusaetzlich zu dem was unsere Distribution upstream bietet brauchen - das sind hauptsaechlich CPAN-Module. Ich kompiliere aber auch einige Software selbst, die wir in einer gaenzlich anderen Konfiguration (im Sinne von optionalen bzw. aus ALternativen waehlbaren runtime dependencies) haben wollen, als die Distribution das bieten kann. Das ist muehsam, und wird deswegen fuer so wenige Pakete wie moeglich bzw. noetig gemacht.
|
nexus_VI
Overnumerousness!
|
Früher häufiger, als ich noch hauptsächlich Gentoo genutzt habe. Heutzutage sehr selten, und wenn dann wird anschließend ein .deb Paket gebaut und installiert. Ich verwende dafür recht gern checkinstall.
|
Lukas
Here to stay
|
Immer wenn ich was selbst kompiliere, dann bau ich daraus ein Paket, und installiere das via Paketmanager. So und nicht anders! Kommt aber tatsächlich sehr selten vor, da Debian wirklich eine große Paketauswahl hat. Wenn ich mal Zeit finde würde ich ja gerne KDE 4.11 aus testing nach wheezy backporten aber ich bin mir nicht sicher ob das überhaupt möglich ist. Daher verwende ich am Notebook aktuell jessie. edit: Unter Arch Linux kam es noch weitaus öfter vor, aber auch dort nur mit ABS und AUR und dann per pacman installiert.
|
Hansmaulwurf
u wot m8?
|
Kein Poll ? scnr Prinzipiell wenig, da ich CentOS verwende @ work, und damit relativ wenig "neueste" Pakete über die repos bekomm, was eigentlich mein Hauptaugenmerk ist (Pakete übern Paketmanager zu holen). Ich brauch auch fast nie die neuesten (nona, dann hätt ich eine andere distri ) Kompilieren tu ich trotzdem recht viel, da wir relativ viele wissenschaftlichen Code haben, und da die Codebasis einfach "von-bis" ist, und vieles Toolboxen oder "experimental" ist. Manche Sachen sind wunderschön dokumentiert und funktionieren ootb. Andere Sachen muss man halt selber Code durchforsten und debuggen bevor der Compiler überhaupt mal was ausspuckt. Das einzige was ich davon abgesehen nie aus repos installier sind VTK, ITK, OpenCV und irgendwas anderes das mit cmake kompilierbar ist (Weil da das konfigurieren so einfach ist, und ich meist bestimmte Features brauch die Default nicht an sind) Aber wirklich großflächig kompilieren und "rumpfuschen" tu ich eh nur auf den privaten Maschinen, aber da ist es sehr ähnlich nur das ich dubiosere Sources auch kompilier
Bearbeitet von Hansmaulwurf am 16.05.2014, 13:44
|
COLOSSUS
AdministratorGNUltra
|
Mir ist gerade aufgefallen, dass ich Nicos eigentliche Frage ja gar nicht beantwortet habe Privat: compton (nicht in Wheezy) Firma: OpenSSL, GMP, Pound, tomcat-native - und noch einige andere Pakete mehr, aber das sind die "aufregenderen".
|
GrandAdmiralThrawn
XP Nazi
|
Arbeit: Roboterarmsimulator der Uni Darmstadt mit OpenGL Frontend, Boost Libraries, ffmpeg, LaTeX, Octave.
Privat: libav, ffmpeg, x264, FileZilla, Truecrypt, xmms1, libsidplay2, resid, X-Chat 2, yasm, pbzip2, HTTrack, remmina, qBittorrent, cloop.
Meistens bau ich, was ich bauen muß, dann aber nicht packaged. Systeme sind CentOS, Debian, und auch schon Mal irgendein embedded Linux, so wie auf der Buffalo Terastation. Oder aber BSD UNIX (Net*, Open*, DragonFly*, Free*, PC-*, Midnight*), OpenSolaris, Haiku OS. Mikroarchitekturen auch verschiedene, x86(_64), MIPSEL, PowerPC, ARM.
Bearbeitet von GrandAdmiralThrawn am 17.05.2014, 21:00
|
Nico
former person of interest
|
ganz schönes spektrum, was ihr an bauarbeit leistet. Hab schon auf einen gehofft, der mal LFS kompiliert hat
|
t3mp
I Love Gasoline
|
Das ist sicher sehr lehrreich, muss aber wirklich nicht sein wenn es Gentoo gibt.
|