Freshports: Funktionsüberprüfung der Ports

[Newsman]

Freshports, die Onlinequelle für die FreeBSD Ports, bietet schon seit 2002 Committern von Ports die Möglichkeit, direkt das Resultat einer Funktionsüberprüfung des jeweiligen Ports zukommen zu lassen. Hierbei wird überprüft ob der Port auch wirklich gebaut werden kann, und wenn es zu Fehlern kommt. werden diese dem Committer des Ports direkt zugesandt. So können diese schneller auf Probleme reagieren, und die freshports Datenbank bleibt immer up-to-date.
Hierüber kann man sich die sanity checks ansehen. Beim Schreiben dieses Beitrags ist der Port “libdnet” hier aufgeführt.
Die News auf freshports gibt es hier zu lesen.
Auch im FreeBSD Porters Handbook gibt es hierzu ein Kapitel.


Original von grUNIX.de

 

[tib]

Heise-Überschrift

Die Formulierung der Überschrift könnte von Heise stammen!

Nur weil sich ein Port kompilieren läst, bedeutet dies in keinsterweise,
dass die eigentliche Funktionalität der Software gewährleistet ist.

Build-Verfication-Test != Funktionstest

Beispiele für den Sachverhalten finden sich in zahlreichen meiner vorgangenen Post.

 

[marzl]

Darum geht es in den Ports auch gar nicht. Die eigentliche Funktion hat der Admin zu überprüfen. Nur zu einem gewissen Teil der Portadmin, denke ich. Der sorgt dafür das das Programm sauber gezogen, kompiliert und installiert wird. Is ja sonst wie in Debian hier :P

 

[tib]

Darum geht es in den Ports auch gar nicht.

Um was denn sonst?
Um zu zeigen, dass ein Maintainer ein Stück Software unter FreeBSD zum kompilieren bekommt?

Die eigentliche Funktion hat der Admin zu überprüfen.

Die Einstellung ist genauso indiskutabel wie zu behaupten, dass lokale Exploits keine Security-Probleme darstellen.

Nur zu einem gewissen Teil der Portadmin, denke ich.
Der sorgt dafür das das Programm sauber gezogen, kompiliert und installiert wird.

Masturbieren mit Software?

Is ja sonst wie in Debian hier :P

Was soll ich mit einem Stück Software das vielleicht funktioniert?
Da sieht es bei Debian etwas besser aus.
Wobei die Maintainer gleich lame sind und nach drei Jahren noch nicht gemerkt haben,
dass der Upstream aktualisiert wurde.

 

[Elwood]

Die Formulierung der Überschrift könnte von Heise stammen!

Nur weil sich ein Port kompilieren läst, bedeutet dies in keinsterweise,
dass die eigentliche Funktionalität der Software gewährleistet ist.

Build-Verfication-Test != Funktionstest

Beispiele für den Sachverhalten finden sich in zahlreichen meiner vorgangenen Post.

Moin,

wie soll das automatisiert funktionieren, der Funktionstest?! Find es schon lecker, dass die Ports zumindest schon mal durch-compiled werden.

Gruss, Elwood

 

[Maledictus]

Schonmal was von Unit-Tests gehört?

Außerdem macht der Build Cluster afaik ein make test für jeden Port den er probiert zu bauen. Was können die Ports/Portmaintainer dafür, wenn sowas Upstream nicht implementiert wird?

 

[tib]

Schonmal was von Unit-Tests gehört?

Außerdem macht der Build Cluster afaik ein make test für jeden Port den er probiert zu bauen.

Leider bieten die wenigsten Programme diese Funktionalität.

Was können die Ports/Portmaintainer dafür, wenn sowas Upstream nicht implementiert wird?

1. NIX!

2.
Warum bringt ein Maintainer ein Stück Software in die Ports?
Hat er es vielleicht selbst mal benötigt?
Benötigt er es noch oder ist es "verwaist"?
Falls verwaist, ist es entsprechend markiert?

Die Frage ist doch, wie gross die Chance ist,
dass ein Stück Software überhaupt funktioniert, nachdem ich es installiert habe!

 

[Elwood]

Schonmal was von Unit-Tests gehört?

Außerdem macht der Build Cluster afaik ein make test für jeden Port den er probiert zu bauen. Was können die Ports/Portmaintainer dafür, wenn sowas Upstream nicht implementiert wird?

Moin,

noe... aber man lernt ja nie aus

Gruss, Elwood

 

[ouTi]

Funktionstest des Ports und nicht der Software.

Der Sinn eines Ports: sauberer Bau einer Software. Wenn also der Port funktioniert, dann braut die Software. Das hat mit der Funktionsfähigkeit der gebauten Software nichts zu tun...