[0.8.2] Ankündigung: KPorts !!! :D

pkg_add -u von NetBSD:

If the package that's being installed is already installed,
either in the same or a different version, an update is per-
formed. If this is specified twice, then any dependant packages
that are too old will also be updated to fulfill the dependency.
....
 
soul_rebel schrieb:
@quarzsnoopy:

hm also ich glaube totsicher arbeitet ncihts was menschen machen und erst rechts nichts was ich vollbringe aber ich geb mir antürlich mühe :D

ich habe auch schon überlegt für massen-updates(alles, x11+kde oder so) alles in ne extra umgebung zu installieren (oder dort die pakete bauen) und beim nächsten neustart vor laden des x-servers die änderungen zu vollziehen (wenn die pakete richtig gebaut wurden und korrekt entpackt werden können).
diese methode ist trotzdem kein allheilmittel, auch beim "pre-basteln" können fehler auftreten die ich nciht vorhersehen kann, besonder die wird dies auch nciht beheben oder umgehen können; außerdem sollte auch ein fehlgeschlagenes portupgrade kein kaputtes system zurücklassen.
Zum Vergrößern anklicken....
Das ist schon richtig, aber hin und wieder habe ich Probleme (und das regelmässig, seit ich BSD habe => 5 Jahre) mit den "p5-..."-Ports unter FreeBSD, die sind installiert aber da fehlt dann EINE Datei, die eigentlich da sein sollte. Dann bricht jeder "make..." und jedes "portupgrade..." ab. Da hilft nur dieses Packet mit nem Knüppel nochmal rein zu prügeln (oft ist das dann aber auch mehr als eines) und dann geht alles wieder. Solche Probleme habe ich in meinem Script mit ner Sandkiste umgangen, in der sowieso zu beginn des Kompilerlaufes NICHTS installiert ist, dann sind alle Packages sauber und ordentlich gebaut (sollten sie jedenfalls)... mehr kann man da nicht tun.
Dabei habe ich zu beginn meiner FreeBSD-Erfahrung ganz schön viele graue Haare bekommen!


soul_rebel schrieb:
auf der anderen seite plane ich ein pkgdb -f einzubauen, dass empfehlungen bei inkonsistenzen abgibt (vielleicht auch auf wunsch eigenständig verscuht diese zu beheben).
Zum Vergrößern anklicken....
...da musst Du aber gut aufpassen, denn was der mir schon für tolle Alternativen angeboten hat... damit hätte ich mir einiges verbiegen können...
Aber wenn Du da eine "eigene Intelligenz"/"Routine" für baust kann das ja was werden. :)
Ist auf jeden Fall ne gute Idee!!!


soul_rebel schrieb:
aber ansonsten würde ich auch allen newbs empfehlen die pakete nciht selbst zu bauen sondern die ausm netzt zu nehmen, freebsd bietet sehr viele an und macht es für den newb fast unnötig je was mit src zu installieren.
Zum Vergrößern anklicken....
Nun, Ansichtssache. Ich habe auch als Anfänger schon lieber kompiliert, da ja zum Beispiel das Binär-Package von OpenOffice englich ist hab ich mir das immer in deutsch gebaut und alles andere dann nach und nach auch Mundgerecht. Leider gibt es jetzt den deutschen Port nicht nehr, da mommt man am Parameter setzen nicht mehr vorbei...
Und hier sehe ich auch den grössten Vorteil von Deinem KPorts, das sich Anfänger die Optionen einkompilieren können, die sie wollen/brauchen, denn als Anfänger hatte ich grosse Schwieriegkeiten immer die passenden/möglichen Optionen zu einem Port raus zu finden! Denn der vorkompilierte Einheitsbrei ist super für Amis, aber alle anderen müssen schon das eine oder andere selber bauen.


soul_rebel schrieb:
nochwas: was ist die -u option für pkg_add? meins hat das zumindest nicht... ist es vielleicht netbsd eigen?
Zum Vergrößern anklicken....
Ja, Du hast recht!
"-u" gibt es in FreeBSD nicht (mehr). Ich benutze pkg_add in FreeBSD schon seit Jahren nicht mehr, nur noch portupgrade.


soul_rebel schrieb:
was spricht dagegen? ich halte es für wesentlich übersichtlicher und sicherer diese files zu editieren als mk.conf oder pkgtools.conf zu editieren.
außerdem ist es einfacher zu implementieren (und ich finde den grundsatz richtig, dass je einfacher die implementierung desto geringer das risiko von bugs). ich muss ja nur die optionen auslesen dann abfragen und den options file schreiben; keine kritischen dateien (makefiles oder zentrale .confs) werden editiert und ich muss nciht mal die conf-files parsen und gegebenenfalls sachen rauslöschen oder ändern. und wieso sollte sich die syntax dort ändern?
Zum Vergrößern anklicken....
Du hast recht, sowas sollte normalerweise nicht vorkommen (aber villeicht sind die ja auch schon von Port zu Port etwas unterschiedlich?). Ich bin auch kein Programmierer (nur Admin), aber ich habe immer befürchtet, das diese "Options"-Files keine einheitliche/standardisierte Syntax haben, da jeder Programmierer sie quasie nur als tmp für Optionen nimmt und so, dachte ich jedenfalls immer, die Freiheit geniesst, die nach seinen Wünschen zu gestallten. Ich habe jedenfalls nur von "mk.conf" und "pkgtools.conf" eine Docu gefunden.
Mit meinem Script (unter NetBSD) lege ich mir meine eigene "globale" conf in der Sandkiste an und bin mir dann sicher das es funzt.
Aber es führen bekanntlich viele Wege nach Rom! Ich erhebe nicht den Anspruch alles zu wissen oder alles richtig zu machen! Wenn es funzt und keinen Ärger macht ist ja gut. :D


soul_rebel schrieb:
und ich kann nachdem vorgang den options file auf wunsch wieder entfernen so dass systemweit keine voreinstellungen zurückbleiben und bei einem manuellen portupgrade die optionen wieder abgefragt würden.
Zum Vergrößern anklicken....
Ich lösche meine Sandkiste mit allen selbst gebauten conf's auch immer wieder automatisch vor dem neuen Lauf. Muss bei einer sauberen Lösung ja auch so sein... :D


soul_rebel schrieb:
und übrigens, kports hat auch nciht das ziel zu einem system für leute mit 10 linken daumen zu werden bzw. klar wäre es gut wenn die damit klar kämen, aber primäre zielgruppe bin ich :D - nein ernst es soll AUF JEDEN FALL AUCH 'ERFAHRENEREN' GERECHT WERDEN, am ende soll alles unterstützt werden was ich auch sonst bräuchte und es soll auch meine arbeit mit den ports erleichtern bzw. beschleunigen.

gruß
Zum Vergrößern anklicken....
Da spricht ja nichts dagegen, wenn es für Anfänger/Pützfrauen (einfach und übersichtlich) UND Profis (alle optionen und Infos) nutzbar ist. Ich dachte so war das gemeint?

Macht aber nichts, ich finde es auf jeden Fall gut, auch wenn es in "Version 1.0" noch nicht alle (evtl.) Wünsche eines Anfängers berücksichtigen könnte. Alles wird ständig verbessert, sicher auch KPorts... :D

Finde auf jeden Fall gut, das Du auf meinen Beitrag so detailiert eingegangen bist. :)
 
hm also gerade ooo würde ich nicht selber bauen, bei dem zeit- und festplattenverbrach, aber naja...

ich werde am 1. september für 5 monate in ein sozialpraktikum nach nicaragua gehen. ich verscuhe mir gerade einen laptop zu orgnaisieren um dort weiterarbeiten zu können (auch wenn meine freundin deswegen stresst macht...).
ich weiß nicht wie es da unten mit internet anbindung aussieht also kann es sein dass updates und releases nur langsam voran kommen in der zeit. ich versuche vorher einen u.u aber wahrscheinlich nicht auch zwei releases rauszukriegen.
netbsd support kommt dann sobald ich den laptop habe und dort neben fbsd auch netbsd draufpacke.
optionen support hoffe ich hinzukriegen aber code rework steht auch an...

asg hat netterweise zugesagt ne homepage zu basteln und steinex hat webspace angeboten; nächste woche werde ich kports.org kaufen und hoffe dann bald allen eine homepage anbieten zu können. deweiteren würde ich mich freuen wenn leute bugs reporten auf der sourceforge seite.
gruß
soul_rebel
 
ein paar fragen...

hallo zusammen, also ich melde mich nach einiger zeit wieder zum status von kports...
erst mal vorweg, v0.4.0 wird im laufe der nächsten woche rauskommen und einige neue features mitbringen wie z.b rund-um-support für portaudit, d.h. neben jeder paketversion (installiert, verfügbar bin and verfügbar src) zeigt ein icon den security status und bringt einen bei knopfdruck zur freebsd referenz für das sicherheitsproblem; und eine große überarbeitung des install wizards (es gibt nur noch einen) mit details zu allen zu installierenden/upszudatenden/.. ports . warnungen aus UPDATING sollen auch automatisch angezeigt werden....

nun zum eigentlichen grund des threads und zur begründung warum ich asg immer noch keine daten für die homepage geschickt habe (sorry axel) : einige sachen zur zukunft von kports sind mir noch unklar, deswegen würde ich gerne von euch wissen was ihr dazu meint:
1. der NAME. undzwar wird kports - hoffentlich ab v0.5.0 - auch pkgsrc unterstützen. das wirft die allgemeine pkgsrc vs ports terminologie frage auf.
zur kurzen klärung für diejenigen denen das problem unbekannt ist: ports heißen unter netbsd portierungen der kernel auf eine platform; in der netbsd terminologie gibt es dafür source packages und binary packages. (das ist nur ein sprachlicher unterschied praktisch ist es equivalent zu ports und packges).
wie soll ich also mit der sprachwahl in kports verfahren? soll ich den namen beibehalten oder einen neutralen namen verwenden wie KBsdPkg? oder soll ich gar das ding KPkgSrc nennen weil die terminolgie einfacher ist?
2. soll ich die unterscheidung in run und build dependencies aufrwecht erhalten oder ist das überflüssig (oder sogar verwirrend...)?
3. soll ich weiter zeit darein investieren, dass möglichst alle feautures auch auf freebsd ohne portupgrade laufen oder soll ich portupgrade vorraussetzen und dafür schneller vorankommen?

vielen dank für eure meinung
soul_rebel
 
soul_rebel schrieb:
...
1. der NAME. undzwar wird kports - hoffentlich ab v0.5.0 - auch pkgsrc unterstützen. das wirft die allgemeine pkgsrc vs ports terminologie frage auf.
zur kurzen klärung für diejenigen denen das problem unbekannt ist: ports heißen unter netbsd portierungen der kernel auf eine platform; in der netbsd terminologie gibt es dafür source packages und binary packages. (das ist nur ein sprachlicher unterschied praktisch ist es equivalent zu ports und packges).
wie soll ich also mit der sprachwahl in kports verfahren? soll ich den namen beibehalten oder einen neutralen namen verwenden wie KBsdPkg? oder soll ich gar das ding KPkgSrc nennen weil die terminolgie einfacher ist?
Zum Vergrößern anklicken....
Ich würde einen Namen wählen der beiden Systemen gerecht wird, zum Beispiel "K-Package-Manager", "KPkgMng" oder eine andere Schreibweise.

soul_rebel schrieb:
3. soll ich weiter zeit darein investieren, dass möglichst alle feautures auch auf freebsd ohne portupgrade laufen oder soll ich portupgrade vorraussetzen und dafür schneller vorankommen?
Zum Vergrößern anklicken....
Wenn Du unter FreeBSD die Packages nicht in einer "chroot"-Umgebung baust, würde ich an Deiner Stelle "portupgrade" verwenden! Wozu das Rad ein zweites mal erfinden???
 
@ tenco: joa das stimmt obwohls hier ja noch noch nicht ganz so schlimm ist wie in den staaten (vielleicht kriegen wir ja gerade sogar eine neue linke in den bundestag :) ).... mein ideologisches favorite unter den oses wäre auch definitiv debian... da kann man sogar
Code: 
apt-get install anarchy
machen :D

quarzsnoopy schrieb:
Ich würde einen Namen wählen der beiden Systemen gerecht wird, zum Beispiel "K-Package-Manager", "KPkgMng" oder eine andere Schreibweise.
Zum Vergrößern anklicken....
hm das hört sich aber zu stark wie kpackage an was es schon gibt, ich glaube es gibt sogar KPkgMng schon, ist ein debian paketmanager... deswegen hatte ich ja KBsdPkg vorgeschlagen, was haltet ihr davon?
quarzsnoopy schrieb:
Wenn Du unter FreeBSD die Packages nicht in einer "chroot"-Umgebung baust,
Zum Vergrößern anklicken....
hm ich hatte das schon überlegt für komplett upgrades da es nciht sehr ratsam ist kdelibs oder xorg-libs upzugraden während man in kde ist... aber warum könnte ich portupgrade nicht in einer chroot umgebung laufen lassen? spricht sonst etwas gegen portupgrade und für pkg_add (außer dass man mit portupgrade keinen custom brefix für binary installs setzen kann)?
 
Hallo,

ich finde: "KPorts" ist ein schöner griffiger Name! :)
Bin für Beibehaltung des Namens "KPorts".


Gruß, Fusselbär
 
soul_rebel schrieb:
3.
soll ich weiter zeit darein investieren,
dass möglichst alle feautures auch auf freebsd ohne portupgrade laufen
oder soll ich portupgrade vorraussetzen und dafür schneller vorankommen?
Zum Vergrößern anklicken....

Hallo,

KPorts soll doch sicherlich eine Hilfe sein,
für Diejenigen, die sich auf der Konsole noch unsicher fühlen.
(Oder für die ganz Bequemen) ;)
Es soll aber doch hoffentlich keine Hürde aufbauen,
sich später mit portupgrade auf der Konsole zu vergnügen,
zumal es ja beim Bau vom X-Server ohnehin notwendig ist.
(Oder z.B. bei den kdelibs)

Darum meine ich, das es nicht verkehrt wäre,
wenn die KPorts Benutzer die Chance hätten,
sich quasi über KPorts mit an portupgrade zu gewöhnen.
Handbuch und Manual lesen und im BSDForen Wiki stöbern
ist natürlich trotzdem anzuraten. ;)

So fände ich also gut, wenn KPorts portupgrade nutzten würde,
wenn es dann obendrein noch einfacher zu realisieren ist,
ist das noch ein Grund mehr, portupgrade für KPorts zu nutzen.


Gruß, Fusselbär
 
soul_rebel schrieb:
... aber warum könnte ich portupgrade nicht in einer chroot umgebung laufen lassen?
Zum Vergrößern anklicken....
Nichts!


soul_rebel schrieb:
spricht sonst etwas gegen portupgrade und für pkg_add (außer dass man mit portupgrade keinen custom brefix für binary installs setzen kann)?
Zum Vergrößern anklicken....

Was ich meine:

Ohne "chroot" ist portupgrade die beste Lösung. (meine Meinung)

Mit "chroot", kann man portupgrade UND andere Lösungen in betracht ziehen. (da habe ich unter FreeBSD noch nichts weiter ausprobiert!)
 
@ fusselbär und steinex:
hm also ihr seit für die beibehaltung von KPorts? ich find den namen auch gut, aber ich denke viele netbsd nutzer könnten sich dran stören...
andererseits muss man ja auch nciht zu allem ne umfrage starten, also werde ich wahrscheinlich den namen beibehalten; wenn ihr ideen oder meinungen dazu habt sagt trotzdem bescheid.
die "yet another"-namen find ich übrigens furchtbar! das kommt für mich nciht in frage, sorry!

@fusselbär 2. :
portupgrade wird jetzt schon voll unterstützt, es geht nur darum, dass ich arbeite die neuen features auch ohne portupgrade zu realisieren; sehr viele tools wie portsdb, pkg_glob, pkg_fetch können nämlich die sache vereinfachen, beschleunigen oder neue features bringen; wenn ich aber für alles versuche das auch ohne die hinzubekommen, brauch das natürtlich extra zeit.
wahrscheinlich werde ich mich darauf konzentrieren basis-funktionalität auch ohne portupgrade anzubieten, aber für erweiterte features brauch man es dann...

@quarzsnoopy:
ok ich habs verstanden :D

danke für eure anregungen

p.s.: man seiten und wiki lesen ist nie verkehrt und wie gesagt, kports soll primär feature-reich sein und nicht übersichtlich im sinne von "es gibt nur einen knopf also kann man nichts falsch machen".
 
Ich denke du solltest voll auf portupgrade setzen. Kein grund das Rad 2 mal zu erfinden, zumahl das ja kein besonders großes Paket ist. Dann ist es schon eher fraglich das dein Programm von einem Riesending wie KDE abhängt.
Kurzgesagt, wer platz für KDE hat, der hat auch noch platz für portsupgrade.
 
v 0.3.9 ist fertig....

hallo zusammen....
also für version 0.4.0 hats nciht mehr gereicht, d.h. ein paar der geplanten features hab ich nicht mehr (stabil) hinbekommen. überhaupt bin ich mit dem release nciht soo zufrieden...
aber ich fahre heute nacht nach nikaragua und weiß nciht wann/ob ich an kports weiterarbeiten kann, wollte euch die neu-entwicklungen der letzten paar wochen aber auch nciht vorenthalten und habe deswegen 0.3.9 rausgebracht!
an neuheiten gibts einiges.... support für portaudit (leider noch nicht wie geplant für abhängigkeiten.. und portaudit -F muss auch noch manuell gemacht werden :( ); das fenster ist insgesamt übersichtlicher geworden, es gibt nur noch einen install knopf und wizard... ; rechts oben gibt es inzwischen ein ubedeutendes aber vielleicht ansprechendes icon (icon packs für mehr ports sind in arbeit); installierte ports können getrennt von verfügbaren betrachtet werden, stale ports werden angezeigt; und die suche erlaubt mehr optionen...
eine homepage gibt es immernoch nicht (axel, hast du meine mail bekommen? melde dich bitte!) - dsa heißt wie immer alles auf www.kde-apps.de - und mit der deutschen übersetzung hats auch noch nciht hingehauen (scriptorius?)... danke trrotzdem an euch beide, dass ihr mithelfen wollt!
wie gesagt ich bin bis anfang februar in nicaragua... vielleicht klappt es da mit dem programmieren, dann gibts weiter updates.. vielleicht nciht... melden im forum werde ich mich auf jeden fall ab und an!
grüße
soul_rebel
 
KPorts 0.6.0 ist fertig

hallo zusammen,
nach fast einem jahr proggen (dabei auch viel sinnlosem alles-neu-implementieren), ist KPorts in der version 0.6 fertig geworden.
an änderungen gibts sehr viel:
- das lange versprochene Optionen setzen geht, auf wunsch für alle ports vor einem "großen durchgang",
- die prüfsummen auf installierten dateien werden gecheckt,
- es gibt eine installationsübersicht auf der einem sicherheits und UPDATING warnungen für jeden zu installierenden port angezeigt werden
- man kann jetzt von installierten ports pakete erzeugen
- es werden einem FLAGS angezeigt (also IGNORED, DEPRECATED usw...)
- die post-install message gibts auch
- man kann seine ports und seinen INDEX updaten
- das programm ist allgemein schneller geworden, lädt dafür am anfang ein bisschen länger und verbraucht mehr RAM
.....
und bestimmt noch andere sachen ;)

ich hoffe ihr probiert es auch und gebt mir ein bisschen feedback.
kritik, bug-reports und übersetzungen sind willkommen :D !

ach ja, ein ports ist auch commited, also müssts auch bald unter sysutils/kports zu finden sein. leider ist ein portupgrade fehler immernochnicht behoben, deswegen müsst ihr einen kleinen patch einspielen, bzw. eine datei ersetzen.
aber das steht auch alles auf der seite!

--> http://kports.sf.net


p.s: wäre cool wenn ein mod den titel des threads in den titel dieses posts verändern könnte, ich wollte keinen neuen thread dafür aufmachen, danke!
 
@kamikaze: ne so einfach isses nicht

@marzl: super ! vielen dank als erstes!
ich habe mir jetzt angeguckt wie man das macht mit den übersetzungen und das HOWTO auf kde.org [1] macht das ganze sehr kompliziert.
ich denk ich hänge einfach die de.po datei an und du öffnest sie mit kbabel (ist in devel/kdesdk3 ). damit kann man recht einfach übersetzungen machen.
wenn du fertig bist, schickst du sie mir einfach zurück und ich gucke wie der sie integriert...

wahrscheinlich kommt sowieso bald ein bugfix release... hab schon wieder soviel bugs gefunden....

danke auf jeden fall für die hilfe!

[1] http://developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i18n-howto.html
 

Anhänge

  • de.po.txt
    46,1 KB · Aufrufe: 389
@marzl: danke! sag bescheid wenn du soeit bist!

ich habe jetzt leider ein problem mit dem port, er ist erstmal auf hold weil es einen angeblichen build-error gibt.
der sieht so aus, dass der testvorgang nach einem erfolgreichen build
Code: 
Fatal error: filesystem was touched prior to 'make install' phase
berichtet.
ich habe dem verantwortlichen für meinen PR gefragt was das bedeutet, aber wenn jemand von euch das kennt, wäre das natürlich auch hilfreich!
info zum fehlerhaften build: http://sce-tindy.tecnik93.com/tb-exp/index.php?action=describe_port&id=961
und der PR allgmein: http://www.freebsd.org/cgi/query-pr.cgi?pr=99653
vielen dank!
 
@unexec rmdir %Dshare/nls/en_US.US-ASCII 2>/dev/null || true
ich glaube als Ersatz hierfür gibt es das neue
@dirrmtry
 
Hallo,

ja das mit @dirrmtry wird imho. über bsd.port.mk abdefiniert,
so das man nicht mehr:
Code: 
@unexec rmdir %Dshare/nls/en_US.US-ASCII 2>/dev/null || true
ausschreiben muß.
So lässt sich dann viel bequemer an ein "@dirrm" einfach ein "try" anhängen. :cool:

Was das:
Code: 
Fatal error: filesystem was touched prior to 'make install' phase
betrifft, da habe ich eben mal nach gegoogelt,
und das hier gefunden:
http://lists.freebsd.org/pipermail/freebsd-gnome/2006-May/014521.html

Da hatte auch jemand die Meldung, mit dem oben angegebenen Fatal error.
Einfach dem Thread folgen.
Wenn ich das richtig verstanden habe, wurde in dem Fall der Tipp gegeben,
das die Abhängigkeiten nicht passen würden.

Vielleicht hilft das ja irgendwie.


Gruß, Fusselbär
 
Mal ein paar Sachen, die nicht ganz richtig sind:
Code: 
bin/kports
bin/kports_client
share/applnk/System/kports.desktop
share/apps/kports/kports-splash.jpg
share/apps/kports/kportsui.rc
share/doc/HTML/en/kports/index.cache.bz2
share/doc/HTML/en/kports/index.docbook
share/icons/hicolor/16x16/apps/kports.png
share/icons/hicolor/32x32/apps/kports.png

Ok.

@unexec rmdir %Dshare/nls/en_US.US-ASCII 2>/dev/null || true
@unexec rmdir %Dshare/nls/POSIX 2>/dev/null || true

nls-Einträge gehören nicht in die pkg-plist.

@unexec rmdir %Dshare/icons/hicolor/32x32/apps 2>/dev/null || true
@unexec rmdir %Dshare/icons/hicolor/32x32 2>/dev/null || true
@unexec rmdir %Dshare/icons/hicolor/16x16/apps 2>/dev/null || true
@unexec rmdir %Dshare/icons/hicolor/16x16 2>/dev/null || true
@unexec rmdir %Dshare/icons/hicolor 2>/dev/null || true
@unexec rmdir %Dshare/icons 2>/dev/null || true

icons* kannst du alle löschen, da sie von misc/kdehier abgedeckt sind

@dirrm share/doc/HTML/en/kports/common

common ist ein symlink und muss als file, nicht als dir, entfernt werden.

@dirrm share/doc/HTML/en/kports
@unexec rmdir %Dshare/doc/HTML/en 2>/dev/null || true
@unexec rmdir %Dshare/doc/HTML 2>/dev/null || true

die beiden HTML Einträge können weg, da sie von misc/kdehier abgedeckt sind

@dirrm share/apps/kports

Ok

@unexec rmdir %Dshare/apps 2>/dev/null || true
@unexec rmdir %Dshare/applnk/System 2>/dev/null || true
@unexec rmdir %Dshare/applnk 2>/dev/null || true

Können alle drei weg (kdehier).

Des Weiteren solltest du bei der nächsten Version das .desktop file für die Applikation gemäß freedesktop.org Spezifikation installieren. Hier ist ein Patch:

Code: 
--- Makefile.am.orig    Mon Jul  3 03:14:03 2006
+++ Makefile.am Mon Jul  3 03:14:32 2006
@@ -36,8 +36,7 @@
 KDE_ICON = kports

 # this is where the kdelnk file will go
-kdelnkdir   = $(kde_appsdir)/System
-kdelnk_DATA = kports.desktop
+xdg_apps_DATA = kports.desktop

 # this is where the XML-GUI resource file goes
 rcdir = $(kde_datadir)/kports

Im Makefile des Ports kannst du die Zeile in der das PREFIX auf KDE_PREFIX gesetzt wird auch löschen. Zu den @unexec... Zeilen siehe Fusselbär.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben